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 <kevin@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
Received on Tue Nov 4 09:38:01 2003