[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

exclusive verses advisory locks

From: Kevin Meinert <kevin_at_vrsource.org>
Date: 2003-11-04 09:21:15 CET

I'm hoping you guys know this already (I hear this feature is a post
1.0.0 thing, I know), but after reading a lot of newsgroups from CVS and
playing with cvs edit/watch, I was frusterated (at some of the CVS
mentality), and wanted to mention/reiterate what I think about exclusive
locking so SVN will (hopefully) provide a useable solution to the locking
problem. I appologize if this is obvious or well known, but hopefully
something here is helpful or illustrative for nonbelievers. I send this
because svn looks so cool (yes drool), and is so close but not yet there
for me because of this one feature. So to illustrate...

I work on projects that are more than 5GBs of art, models, sounds,
textures, word docs, and code (like 1% of the 5GB is code)... Most of
the data is binary files that cannot be merged automatically or easily,
but require source control. These files are edited by non-technical
people who also need a graphical frontend to source control, and by
technical people who also use the same database for code (who may bypass
the graphical frontends or not depending on their comfort level).

The source code is developed as usual in parallel, but...
Our art data requires exclusively locked (enforced) checkouts. The
source control tool (i.e. svn), would need to make sure no two
art files were checked out at once. An artist could waste hours if they
had to hand merge say, 3D models from 3dsMax or Maya (imagine no cut
and paste in Word)... Not to mention they couldn't hope to perfectly
duplicate the original work. It would truely be a loss of time
money and possibly quality.

I hope this outlines the importance for exclusive locks that are enforced
(of course you can always override by chmoding just like with VSS, but you
should and would know better to check something in that way). The
enforcement would need to be that if you are editing, there is no chance
someone else will slip in a commit behind your back.

This would need to be selectable by an admin per file. Access control
would be useful and a requirement for some organizations.

I agree that for source code, non locked or simple advisory locks are good
                        (and exclusive locks should be discouraged).
But the flip is true for binary data: exclusive locks should be
encouraged, and IMHO are nessesary for a source control tool to be of any
use to a serious developer (one with tight schedule/money, or just cares
about reducing chaos)...

I love the utopian development philosophy of CVS, but it is useless as a
serious multimedia development tool when managing GBs of binary art data.
Please don't model SVN after CVS in this respect (I'm talking about cvs
watch and edit...).

What's sad is that VSS works better than SVN for us, simply because SVN
doesn't have exclusive checkouts yet.

There is a time and place for concurrent development, and a time and place
for exclusive. If SVN can mix them elegantly you'll have something

thanks for getting this far
<step off soapbox>

Kevin Meinert                         /_/                  
home - http://www.vrsource.org/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 4 09:19:44 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.