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.
Here are some key things I’ve found that are particularly detrimental for artists: Sounds like you’re already committed to SVN. Limitations from client side disk i/o are much reduced, possibly at the penalty of increased network traffic. 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. 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. When you are working with big files this ends up taking FOREVER. 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.Ĭhecking in a new version of a file involves a binary diff between the pristine file and the modified file on the same disk.
Subversion has a wierd meechanism for storing files in your checkout location. The real holdup on all of our projects has been client side disk performance. however this came at a price, the webdav module feels a lot less responsive than the native subversion protocol. 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. I’ve been able to achieve really consistent performance with a group of about 30 artists committing reasonably sized models. This volume hosts a standard FSFS backend SVN filesystem. The SVN server uses iSCSI (software mode) to mount the XFS volume. Jumbo frame enabled 1GB ethernet.ĥ terabytes of raid 5 on fairly standard SATA drives