Version Control for Graphics

Question

Say that the development team includes (or uses) graphs that create all the images that are included in the product. Such things include icons, bitmaps, window backgrounds, button images, animations, etc.

Obviously, everything needed to create a piece of software must be in some form of version control. But most developer version control systems are primarily for textual information. Should graphics users use the same version control system and repository as encoders? If not, what should they use, and what is the best way to keep synchronization?

Answer 1

Yes, having art in version control is very helpful. You get the ability to track history, roll back changes, and you have one source for backup. Keep in mind that there are MUCH more art assets, so your server must have a large amount of disk space and network bandwidth.

I had success using perforce in very large projects (+100 GB), however we had to wrap access to the version control server with something more user-friendly.

I heard about the good things about Alienbrain , it seems to have a very smooth interface.

Answer 2

GitHub recently introduced “image view modes,” see: https://github.com/blog/817-behold-image-view-modes .

Answer 3

We also just put the binaries in the source control. We use Git, but this also applies to Subversion.

One of my suggestions is to use SVG where possible, because you can see the actual differences. With binaries (most other image formats), the best you can get is version history.

Answer 4

Many people with a graphic type will want something more complex than subversion. Although this is good for version control, they need a content management system that allows you to cross-reference assets, tags, thumbnails, and similar things (as well as version control).

Answer 5

TortoiseSVN can show image changes side by side, which is really useful. I have used it with different teams with great success. Artists loved being able to roll things back (after they got used to concepts). However, this takes up a lot of space.

Answer 6

I would definitely put the graphics under version control. The difference may not be very useful from a comparison tool such as diffmerge, but you can still check the two versions of the graphics and look at them side by side to see the differences.

I see no reason why the resulting graphics should not be stored in the same version control system as the encoders. However, when you create graphics using PSD files or PDN files, you can create a separate repository for them, because they have a different context for the actual jpeg or gif end that is created and deployed using the developed application.

Answer 7

@lomaxx TortoiseSVN includes a TortoiseIDiff program that looks like diff for images. I did not use it, but it looked intriguing.

Answer 8

Interest Ask. I do not have a lot of experience working directly with the designers of the project. When I have it, it was contracted, where they “delivered” the design. I have done some of my own design work for both websites and desktop applications, and although I have not used source control in the past, I am implementing SVN for my own use as I start to do some paid freelance Jobs. I intend to use version / source control in the same way as with source code. It just becomes another folder in the project's connection line. The way I worked without source control is to create a resource folder that contains all the media files equivalent to the source code. I like to think of Photoshop PSD as graphical source code, while JPEG output for a website or otherwise is a compiled version.

In the case of working with designers that I come across in the near future, I would like to try to regularly check their various versions of their source files. I will be interested to read what others with some experience will say in response to this.

Answer 9

In my opinion, Pixelapse , combined with a backup solution, is the best version control software for graphics I've found so far. It supports adobe files and a bunch of normal bitmaps. It has a preview version. It is autosaved when updating files (when saving). It works like a dropbox, but has a great web interface.

You can use it in teams and share projects with different people. It also supports endless reviewers, which are great for design agencies. And if you want, you can publicly collaborate with projects that are "open".

Unfortunately, you cannot have a local pixel pixel server, so for backup, my current setup is that I have a Pixelapse folder (like Dropbox folder) inside the git repository to take snapshots.

Answer 10

We use subversion. Just put the folder under / trunk / docs for comps and ask the designers to check and commit this folder. Works like a champion.

Answer 11

Regarding differences and merging, I believe version control is more important for graphic and multimedia elements. If you think about it, most designers will be the sole owners of the file - at least in the case of graphics - or at least I would think so. I would be interested to hear from the designer.

Answer 12

@Damian - Good thought on tagging and cross-referencing. It's true; while I do not work with many designers in a software development project, I worked for a company that has a design department, and I know that this is a problem. Designers are still (constantly) looking for the perfect system to manage such things. I think this is more suitable for the design department for sharing, searching and versioning, etc. To all assets - where there is an incentive for business not to reinvent the wheel wherever possible. I do not think that this will be applied in a project-oriented manner, since labeling and cross-references will not be equally applicable.

Answer 13

We save binary files and images in version control using Perforce. It's great!

We store many pieces of art, and it scales well for a large number of large files. It recognizes binary files, which cannot be distinguished, and saves them as full copies of files at the end.

It has a P4V (cross-platform visual browser) and thumbnail, so image files can be seen in the browser.

Answer 14

You might want to take a look at Boar: "Easy versioning and backing up photos, videos, and other binary files." It can handle binary files of any size. http://code.google.com/p/boar/

Answer 15

A free and slightly winning solution is the Adobe Cue version that ships with Adobe Suites up to CS4 and is easy to install and maintain. Offers user level control and artist friendly. Adobe has stopped supporting, although it’s a shame for her. Adobe Bridge acts as a client between the user and the Version Cue server. If used correctly, its inexpensive version control solution. I am using CS3 version of cue with CS3 Bridge. Great for small teams.