Image via Wikipedia
While it's Windows only for now, it shows that Adobe is committed to DAM and Versioning, despite its decision not to continue development of Version Cue. When CS5 was announced, I got a lot of negative feedback from my customers who depend on Version Cue for project versioning and PDF review management. The killing of VC left them wondering where to turn for version control in the creative space as they transitioned to CS5.
While tools like Subversion and Git are popular in the software development arenas, there aren't integrated solutions for the graphics community to those repositories. Other DAMs and VC platforms exist, but their interfaces are often clunky and require several steps to check parts of a project in and out.
Version Cue provided in-app support for version inspection and reordering, allowing the user to promote a previous version to the current one without losing the current version. This would send a signal to everyone working on the project that the asset had changed, and that they needed to update it. VC also prevented simultaneous editing of graphics (Illustrator and Photoshop) and documents (InDesign and InCopy).
This quiet revelation has me itching to see the released product. I am eager to see whether it will include Git and/or Subversion connectors as well.
For Creative Suite integration with Subversion you can use PixelNovel Timeline (http://pixelnovel.com/timeline). It doesn't work as a Bridge connector, it integrates directly into the host application UI (only Photoshop at the moment, Illustrator and InDesign coming soon).
Adobe Drive 2 conceptually sounds cool. But under the hood using SOAP/XML to encode large binary digital asset is a poor idea from a performance & scalability perspective. In other words, pie in the sky architects came up with Adobe Drive2 and the idea to use SOAP based Content Management Interoperability Services (CMIS) . This may be some what ok for CMS, where you publish once in a blue moon to a web-site smallish png/html/css files but for the creative workflow during production as many large sized assets are churned (2GB PSd file anyone ?) this strategy totally breaks down. What we need is a versioning system that is designed to scale up for binary assets. Subversion is optimal for text files used in software development. In my search for a version control system the best of the breed I have found is Evolphin Zoom or Perforce . Zoom is designed for the artists while Perforce has a very 90s UI feel to it and is also optimized for software development. Zoom is the only solution out of the box that supports all the Adobe CS Apps - Photoshop, Illustrator, InDesign, Flash, Dreamweaver, Fireworks etc
While I appreciate your zeal for Zoom, you might want to look at Adobe's CRX. When Adobe acquired Day software last year, it got not only its flagship CQ Web Content Management system, but also it got CRX and the DAM that goes with it. We have been actively pushing CRX to its limits with respect to digital asset management with version control. In addition, it features event-based workflows that allow you to add an asset to the DAM and have metadata applied, different versions created, emails sent to appropriate people for approval, and more.
It also has an extremely robust search engine that offers full text search of Office, PDF, text, and more document types as well as complete metadata search. The DAM can be mounted on the desktop via webdav, CMIS, and other protocols for quick access by any application, including the ones you mention.
In addition, CRX can cross-connect to other DAM systems and provide federated search across DAMs. It can also scale and be run in cloud environments. I encourage you to take a look at CQ and CRX as you are awarding your next "best of breed" labels.
James:
Great article on Adobe Drive. I was wondering if you could give me some advice. I have a client who publishes student text books in Spanish. They're looking to create an editorial workflow with a very limited budget. Woodwing, K4 and other publishing systems are out of the question at this time. So, I've suggested using Adobe Drive 2 for a short term solution.
Where this gets complicated is that they have editorial teams in two different locations. They are paying a bunch of money to setup a system where both teams can work together by having two servers (one at each location) mirroring the data. According to the IT guys the server would show up to both teams on their own network with the same name. And, I'm starting to wonder if Adobe Drive installed on one of the servers would really work. They tell me they'll use NetApp for replication and Microsoft DFS for something along the lines of hiding the server name or something to that extent. Do you have any thoughts on this that you can share? I would really appreciate it. Thanks so much.
Best Regards,
Jose
Last week, Adobe released Drive 3. While it no longer supports Version Cue, it DOES support CQ DAM, formerly Day DAM. I remembered this post from last year. If you haven't looked at Drive 3 and you're a CQ customer, go check it out.
Jose, Drive wouldn't live on a server. Rather, it can be used to connect desktops to a CMIS or Adobe Digital Enterprise Platform server (also known as CQ). In your case, you might look at Alfresco Community Edition. Drive 3 can connect to that, so you would put one in a place where both sites can "see" over the network. Both sites can then connect to the repository through Drive, and you will then be able to check content in and out of the repository from Bridge or the desktop. That might get the job done...