You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Meinert <ke...@vrsource.org> on 2003/11/04 08:21:15 UTC
exclusive verses advisory locks
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
special...
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
Re: exclusive verses advisory locks
Posted by Ben Collins-Sussman <su...@collab.net>.
We plan to support both advisory and exclusive locks in post-1.0
subversion. Take a look at our design in the notes/ directory (which at
the moment, is only about exclusive locks):
http://svn.collab.net/repos/svn/trunk/notes/locking-plan.txt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: exclusive verses advisory locks
Posted by Timothee Besset <tt...@idsoftware.com>.
You might want to look at some design work I've done around large media
management with SVN for a project called YAM:
https://zerowing.idsoftware.com:666/yam-web/index.html
the design effort sits in a wiki:
http://zerowing.idsoftware.com/wiki/
I know at least one full scale game that's being produced with the help of
SVN. While I acknowledge locking is important when dealing with binary
data, I don't think it's an essential requirement. YAM doesn't have much
working code to provide at this point, but has a rather solid design. It's
sleeping till me or someone else has time to work on it some more.
TTimo
On Tue, 4 Nov 2003 02:21:15 -0600 (CST)
Kevin Meinert <ke...@vrsource.org> wrote:
>
> 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 special...
>
>
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org