Yes, version control definitely seems like one of the biggest gaps. The communication between developers and designers have to improve, and the developers will have to realize they can't ask every designer for commits, but they can probably ask them for .zip files.
On the other hand, maybe we should make designers want to use Git.
This might be not as crazy as it sounds, as I recently learned:
A few weeks ago, there was a short presentation about Git, targeted at non-programmers such as graphics and web designers. After the presentation, one of the designers (who apparently already knew about Git) stood up and criticized the presenter for not going deeper into branches and auto-branching.
Of course, the presenter intentionally left that topic out, in order to not confuse all those Git newbies.
However, the designer argued that this is what would make Git interesting for designers. He said that all this diff/commit/push/pull stuff was boring for designers where a "diff" between graphics files is neither readable nor meaningful, and where automatic merges are impossible anyway. But branching has the power to reflect the natural work-flow of a designer who permanently goes back to previous versions in order to try different variants. Reflecting this via "Save as ..." (and naming files accordingly) is very cumbersome.
Although I personally think this guy overrated the power of branches, this might change once the Git user interfaces becomes simpler to use, more targeted to designers (rather than just software developers) and better integrated into graphical tools like Gimp, Inkscape or even Photoshop.
Source control is also not part of a designer's natural workflow because the options aren't that great (usually backups on a NAS is all there is and a few proprietary snapshot plugins from Adobe. Kaleidoscope looks the most interesting). Also, svn branch numbers or git hashes don't make nearly as much sense to designers as "HiFi Mockup iPhone4 Right Aligned Inbox.ai" when they want to backtrack or compare current "in the running" designs.
I'd love to see the OSS community develop better source control software targeted towards designers. :)
> svn branch numbers or git hashes don't make nearly as much sense to designers as "HiFi Mockup iPhone4 Right Aligned Inbox.ai"
That's what the commit comments are for.
BTW, programmers also prefer reading commit comments, commit dates and author names. They don't read hashes. (Although they sometimes copy&paste them because they are short and unique.)
Yes, I just picked up git for Windows, and it is atrociously unusable. Brutally atrocious. It's not like Windows is a popular operating system - git shouldn't support it as a first-class citizen. ;)
I've been using the whatever default Windows port that is linked from Git's download page for several months bow and there is nothing atrocious about it. It works well and it does differ much from the Linux version. (edit) The command line version that is.
git gui works wells for me on Windows with msysgit. It's ugly, and there are a good number of small issues, but it definitely provides a reasonable user experience.
And of course, the command line option through msysgit is great.
Since the target group were designers, the presenter used a Mac, and tried to do everything using a GUI client for Git.
I don't remember which one he used, but it ran natively on the Mac and it looked quite nice.
(Still, the presenter sometimes struggled with that GUI. He was obviously more used to the command line.)
Most git actions don't need a deep understanding of Git nor a full GUI to function. I think git gui and gitx probably are enough to get a designer going.
What Git really needs is a few tools like Versions and Cornerstone were for SVN: simple apps that didn't require any command line use at all. Git Tower might be there, but I haven't used it so I can't say that 100%.
Simple pixel-by-pixel "diffs" are of course possible, but only useful in trivial cases.
What if someone changed the color scheme (which affects almost all pixels)? What if someone moved some part of the image to another part? What about resolution/size changes and multiple layers? What about vector graphics?
And the most important thing: How to display that in a way to be easily understood by non-technical people?
For hard-core techies, there is of course the option to use a text-based image format. For raster graphics, the "plain" variants of PNM come to mind. For vector graphics, SVG or EPS might be good choices. Then, a good (indention-aware) textual diff should produce sensible results - especially if only details were changed.
"merge"
Automatic merges are only useful if they aren't too "clever". That's important for text and especially important for graphics.
So if two distinct areas of an image are edited, a simple merge can and will work. But overlapping changes or even global changes should always result in a conflict.
However, if only trivial merges are desirable, most changes will cause conflicts, which would be not much different from the current situation.
Also, that kind of merges will already happen automatically with the current (text) merge anyway, provided that formats like PNM, SVG and EPS are used.
I don't think image comparison is the problem here. The problem is that designers works in rather different flows. To us a file can be many different states at once.
Kind of like a developer would have 10KLOC but be commenting the 8K of them in and out all the time.
In other words the document have many states at once depending on what you make visible or not.
Git and similar tools are designed to track multiple revisions of a file. Imagine the history feature (undo/redo) from your favorite editor, but for saved files, and with the ability to point to two arbitrary versions and ask, "What changed between these?"
On top of this, Git added the ability to merge changes together automatically. Imagine that one person changed a bunch of stuff in the first paragraph in a document, and someone else changed a bunch of stuff in the second paragraph, and the computer could automatically merge those changes into one document.