Hello,
Has anyone had any experience integrating Subversion into their pipelines? I’m preparing to implement Tortoise SVN to handle our Max and Maya work. What’s the general consensus on this kind of revision control? Thanks!
I’ve worked with tortoise and perforce and I think it’s mandatory in any production =)
Some people will still save out different versions locally (animators like it a lot), but if you have a team of people working on something, being able to revert their changes is invaluable.
It’s the bare minimum you need! For assets though you should probably write a dependency tracker that sits on top of your repository / database of chaise!
SVN can be very slow with large binary files, so beware (though this was SVN a few years ago, has it improved?). So just be wary. But like already said, you need some versioning system and there’s no excuse not to have one.
[QUOTE=Rob Galanakis;8426]SVN can be very slow with large binary files, so beware (though this was SVN a few years ago, has it improved?). [/QUOTE]
still slow…
I know that git is far speedier than svn, but I’m unsure of speed tests with large binary files.
[QUOTE=ArrantSquid;9354]I know that git is far speedier than svn, but I’m unsure of speed tests with large binary files.[/QUOTE]
Git on Windows has serious problems with large files. You will constantly get out of memory errors.
Svn is still slow. It’s big hold up is how bad its working copy management code is. Svn 1.7 is supposed to fix this. Using a very fast hard disk (ssd) on the client can alleviate this to a large degree. Also do not use the Webdav module. It just makes the already mediocre performance even worse.
Perforce is the king of general purpose revision control for large binary files. To get much faster you would need a special purpose asset management system
My setup
SVN Server
4 core ubuntu linux 8.04 box
8 GB of memory
Local storage: 500GB, mostly unused
Network. Jumbo frame enabled 1GB ethernet.
iSCSI Server - Buffalo terrastation
5 terabytes of raid 5 on fairly standard SATA drives
Jumbo frame enabled 1GB ethernet
One MASSIVE XFS volume in the 5TB raid
The SVN server has two nics. One is pointed at the iSCSI server. The other at the LAN.
The SVN server uses iSCSI (software mode) to mount the XFS volume. This volume hosts a standard FSFS backend SVN filesystem.
I’ve been able to achieve really consistent performance with a group of about 30 artists committing reasonably sized models.
I use the WebDAV module for SVN, which makes it easy to integrate authentication with Active Directory, allowing for fine grained per user/per project access controls. however this came at a price, the webdav module feels a lot less responsive than the native subversion protocol.
The real holdup on all of our projects has been client side disk performance. Subversion has a wierd meechanism for storing files in your checkout location. It stores a pristine copy of each file in a hidden folder (.svn), so a checkout involves a download, a disk to same disk copy, and a hash check.
Checking in a new version of a file involves a binary diff between the pristine file and the modified file on the same disk. When you are working with big files this ends up taking FOREVER. A fast disk would be a big help here, as TortoiseSVN often appears unresponsive or shows a 0% transfer rate for a very long time on checkins.
This is why I would imagine perforce is faster, because I believe it only stores a single copy of each file on the end users machine. Limitations from client side disk i/o are much reduced, possibly at the penalty of increased network traffic.
[QUOTE=JonnyRo;9967]
This is why I would imagine perforce is faster, because I believe it only stores a single copy of each file on the end users machine.[/QUOTE]
Yes, Perforce maintains all revision data in its depot database, and you have some specific changelist/revision point sync’ed locally, + of course any files you have checked out and revised. However, for binary data I believe it stores the entire binary with each revision on the depot, not just a delta like it does for textual data (for reasons which are understandable). What I’d be interested to know is if there are other asset management systems that are more efficient in handling binary assets.
Sounds like you’re already committed to SVN.
Here are some key things I’ve found that are particularly detrimental for artists:
- I’ve found the basic architecture of SVN (and even more-so with Git) is just non-intuitive for non-techy people like artists and designers. Perforce’s “library book” model, where one checks out a book, and check’s it back in when your done is far more intuitive and easy to explain. SVN and Git’s model of “i have everything and push my changes to everyone else” can be difficult to grasp for some folks in my experience.
-moving assets within an SVN repo (re-organizing) is a headache; Dragging folders (most artists preferred method in my experience) is simply out of the question and will instantly corrupt your local repository.
-if you work with a lot of largeish files with several to many revisions, be prepared to need a LOT of disk space. All revisions are stored locally.
-though rarely an artist task, merging files (xml, code, etc) in SVN (and Git for that matter) is absolutely atrocious. SVN actually destroys your local copy of a file prior to resolution when you have conflicts. It inserts >>>>>>> indicators and other information directly into the file where the conflicts occur. (Perforce is soooooo much better at merging than SVN and Git)
-as mentioned before, it’s really pretty slow. At least when compared to Perforce.
-branching and reintegrating can be cumbersome. SVN branches are essentially just complete copies of an entire repo soaking up even more disk space, whereas SCM’s like Perforce use virtual copies; only files you actually change exist on disk as another branch.
-Tortoise’s shell integration is a nice feature in theory, but unfortunately doesn’t work so well. The indicators of when/if you have changes on folder and file icons are rarely accurate and almost never refresh correctly. This can become quite confusing for non technical people.
-While other SVN GUI’s offer more stuff than Tortoise, I have found them all to be really poor tools. SmartSVN, for example, is written in Java, and runs out of memory a LOT. It also runs very, very, VERY slowly. 
There’s probably a few other things, but those are the biggest in my mind.
[QUOTE=sl4ppy;11667]
- I’ve found the basic architecture of SVN (and even more-so with Git) is just non-intuitive for non-techy people like artists and designers. Perforce’s “library book” model, where one checks out a book, and check’s it back in when your done is far more intuitive and easy to explain. SVN and Git’s model of “i have everything and push my changes to everyone else” can be difficult to grasp for some folks in my experience.
[/QUOTE]
Well, you can set up Subversion so your local files are read-only and you have to specifically check them out/open for edit. That’s how I always use Perforce. In terms of how SCMs manage revisioning, I do prefer Perforce’s changelist approach to grouping and tracking changes.
[QUOTE=sl4ppy;11667]
-moving assets within an SVN repo (re-organizing) is a headache
[/QUOTE]
I definitely like Perforce’s approach to branching and integration. I found the Subversion approach somewhat confusing, but admit I might not have given it enough time. I can’t imagine asking artists to do branching and integration, though, well frankly, in either Perforce or SVN…
[QUOTE=sl4ppy;11667]
-though rarely an artist task, merging files (xml, code, etc) in SVN (and Git for that matter) is absolutely atrocious. SVN actually destroys your local copy of a file prior to resolution when you have conflicts. It inserts >>>>>>> indicators and other information directly into the file where the conflicts occur. (Perforce is soooooo much better at merging than SVN and Git)
[/QUOTE]
I agree with this. I would expect most people would want to use and external diff/merge tool which understands the SCM in question to do this. In my relatively light weight at-home use of SVN, I use a package within Emacs for an SVN frontend, and a difference/merge package built in to Emacs to do that work. It avoids the problem you mention. I imagine (but can’t swear to) Araxis Merge can deal with this just fine, and is thought of at my work as being superior to the Perforce diff/merge tool. I’ve found the Perforce diff/merge tool to be good and so haven’t invested in Araxis. Based on the info on their site, it appears to work with almost every imaginable IDE and SCM.