Using Subversion for graphic design files and other binary assets | Hacker News Reader

Using Subversion for graphic design files and other binary assets

subversion.wandisco.com

36 pointsjameseh18 comments

Anatoly Paraev talks about how his company, PixelNovel, is getting their developers to use Subversion.

I've worked with a large team of artists and we had an art repository of around 125GB and maybe 10000 changes. Subversion worked really well. We used the tortoise interface and after a few weeks everyone got used to it.

Adding plugins for specific apps is a good idea. I had previously used Alienbrain and the only real difference was the plugins (AB had plugins for MS Office, 3DSMax, Dev Studio and Maya) and an interesting bucket backup system where you could back up legacy checkings making the database smaller and significantly faster. At the time we had a database of about 1TB and most of it was in bucket backups.

Another interesting feature was the workflow where an artist would checkin an item but it wouldn't go into the main development branch until a senior artist has checked the work. This was a nice idea but proved to be too time expensive for our senior artists who of course were not paid to be gatekeepers and were the best artist we had so management preferred them to actually make things!

The least interesting thing was the price per seat which was around £1000 per year and a support contract which grew depending on the size of your team (this was about 8 years ago so I may be off on the prices then and now).

Although Alienbrain was cool my personal feeling was that the money was better spent on a little bit of training and a subversion system. As long as your team is smaller then say 50 artists and developers.

As an IT consultant, I once got a completely non-technical client using SVN for all their documents. With a little guidance on the use of TortoiseSVN, they soon came to love it. Years later, they're still using it. SVN isn't just for developers!

I would guess the hardest part is teaching non-technical types the concepts of version control, especially one like subversion.

Were there any tricks in doing that kind of teaching?

Introduce it slowly! Make sure the language you use matches the language of the problems they're trying to solve. And write a document which explains how to do the common tasks, click by click.

Once you've got the basics sorted, progress to showing them tricks, like fishing out old versions. And whenever you do stuff to help them, always show them what you did. Nothing helps learning like a pressing need to get something done.

I've had similar reactions from Project Managers after I showed them some versioned Excel files. They were blown away by the ability to go "back in time without having to manage copies". The revision graph totally floored them.

There's an opportunity here somewhere... take TortoiseSVN, remove all ability to branch/merge and anything beyond taking a file forward and backward in a timeline, make it stupidly simple and use words that non-technical people understand. And then sell it as the "time machine for files".

For recurring income, make it a DVCS (so start with TortoiseHG instead of TortoiseSVN) and offer to back up their files for $5/mo and make the "backup" a `hg push remote`

I'm telling you, it's amazing how few people who work with computers and digital files all day long have _no_ idea about cvs,svn,hg,git, etc.

They think that if it's not handled by the display application (Excel, Word, etc), it's not possible. They have no conception of doing stuff on the file level.

The GPL license may be an impediment to this plan, and the DVCS concepts will probably be far too complex when dealing with non-technical people who just want to work together.

My experiences suggest that the money would be in setting up and training, rather than a product as such. I did think about it carefully and design something (easier tools, server side search), but really it didn't seem worth it.

Dropbox is trying to do this, they seem to be making some progress.

If the overhead of a subversion checkout storing each file twice is too much for your dataset and drive, you might take a look using scord with subversion, which allows your checkout to store only one copy of each unmodified file. http://scord.sourceforge.net/

A little more detail: In addition to the working copy of a file, a subversion checkout includes a pristine version of each file for diffing (e.g., 'svn diff', as well as to make 'svn update' and 'svn commit' more efficient). scord is a Linux and Mac OS X FUSE file system that mediates access to a directory tree, detects when a pristine and working copy pair contain the same content, and keeps only one copy around in these cases.

I store my photo album in subversion - I love not having to worry about accidentally losing a photo. Halving the disk space needed for the checkout lets me fit my photo album into my laptop harddrive.

Disclaimer: I'm the primary author of scord.

I work for a dev company that does a lot of Photoshop and have pointed our head of design at this product.

PixelNovel should look to integrate their ComparePSD product into the plugin as well. It would be quite beneficial to be able to do a granular diff of the photo properties across two versions of the .psd.

We also noted in a discussion, it'd be beneficial if you could overlay two versions of the .psd file and have the system highlight the differences. (E.g. you darken the eyes in the latest version, and when overlayed over the previous version, there'd be a light yellow circle drown around the eyes to make the change apparent).

Hi, Thanks for your suggestions.

We are going to integrate ComparePSD into Timeline very soon - in fact the integration was the reason we created comparePSD in the first place, it's just that we keep having higher priorities all the time.

We'll think about your overlay suggestion though I have to say it's bit more difficult than just comparing layers. Please let us know if you have any other suggestions or questions: support at pixelnovel dot you-know-what

As for diff'ing two images (image A and B), assuming there's a picture that represents the diffs (image D), if you did a pixel by pixel comparison of the two images (A & B), if the two pixels differed in color, you could simply display that pixel in a complimentary third color on image D (or allow the designer to see all conflicting pixel in a single, consistent color which would show clusters of colors where changes had been made). Just a thought.

It has always seemed to me that a traditional CMS was a better path for creative archiving than a version control system, but that may just be me. A CMS can do things like allow you to manage a PS document while publishing it's flatter JPEG to your web site or a print image in a Quark layout. I guess if you just want to back up different version than a version control system would do just fine and is simple but a CMS can save so much time and there are plenty of good ones that are free.

Very nice plugin for photoshop! I don't have a lot of experience with this, but anecdotally I've had better experiences using git with bunches of binary files than SVN. Maybe it had something to do with the structure of the binaries, but I was always and forever getting conflicts and such in SVN - or maybe it was the way my old company set it up, who knows.

a photoshop plugin is genius. the graphic designer on our team was able to use an eclipse plugin to update/commit. we've switched to git which doesn't have any nice gui's (smart git is best so far...thinking of buying it) so i do all his pulls/pushes.

We just taught our graphic designers how to use git. Yeah, it’s a command line interface, but really once you’ve had an hours training on the basic concept and been given a cheatsheet it’s not difficult.

I wonder if anyone here could comment on using subversion with mod_dav_svn. One downside is that you lose the ability to comment on changes, but the upside is that your users just see it as a regular web folder.

Thoughts?

It works pretty well within its limitations, but other downsides are:

* If your program creates a temporary file on the webdav file system, it ain't temporary, it just became version controlled. :-(

* You tend to get a lot of versions, all looking alike. It becomes somewhat more difficult to determine which version you want to roll back to if you need to. In addition, it takes up a lot of disk space to maintain lots of (unnecessary) versions, especially if they are binary blobs.

Both of the above drawbacks can be worked around by copying the file off the webdav file system, editing it, and then copying it back on. In the case where I saw this done, most (all?) of the users ended up switching to TortoiseSVN and stopped using the webdav interface.

Also on HN:

"Git: A Designer's Perpective": http://news.ycombinator.com/item?id=774983

Reply on news.ycombinator.com