Getting Lock/Modify/Commit cycle out of SVN

[se...@dimensionalrift.com]

    Has anyone tried to coerce SVN into providing a Lock/Modify/Commit
style?  In order to manipulate large numbers of binary assets properly
this is necessary, but goes against the SVN's (and CVS's) model of
update/modify/update/merge/commit.  It seems the properties could be
used for this provided a custom(ized) client existed that could
properly change the properties to simulate the file locks in the
metadata.  There's probably a lot more to it but I don't know the
system very well to know what any other isues/gotchas could be,  like
any strange interaction with the properties and versioning & branching
for example.

    As far as I can tell, the real trick would be to get it working
automagically for files under a directory structure or based on
extension.  My line of thinking is to attempt apply this to art
assets, for anywhere from 10000 to 200000 files using roughly 50-100GB
of data worst case (though the backend DB would likely end up a few
times larger than this once the histories start showing up).  Any
thoughts/issues on scaling that high with both SVN and Berkeley DB?

    Having the .svn magic local backup copy of the file would also
probably be unnecessary in this case as well but I've seen that thread
go by a few times already . . .  Definitely not a showstopper compared
to the above subjects . . .

    I hope these numbers don't scare anyone :) . . .

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Getting Lock/Modify/Commit cycle out of SVN

["Glenn A. Thompson" <gt...@cdr.net>]

Hey,

seanc@dimensionalrift.com wrote:

>    Has anyone tried to coerce SVN into providing a Lock/Modify/Commit
>style?  In order to manipulate large numbers of binary assets properly
>this is necessary, but goes against the SVN's (and CVS's) model of
>update/modify/update/merge/commit.  
>
While L/M/C is a valid and useful model, U/Md/U/Mg/C also works for 
binary documents.  As Ben said in his response, the locking can improve 
communication for more general document management but other local 
methods can be used to accomplish the same goals. 

>
>    As far as I can tell, the real trick would be to get it working
>automagically for files under a directory structure or based on
>extension.  My line of thinking is to attempt apply this to art
>assets, for anywhere from 10000 to 200000 files using roughly 50-100GB
>of data worst case (though the backend DB would likely end up a few
>times larger than this once the histories start showing up).  Any
>thoughts/issues on scaling that high with both SVN and Berkeley DB?
>
I don't believe BDB will handle this well (others may).  But not to 
worry,  Once a pluggable-db gives way to a SQL FS this problem will go away.
This is my mission.  I'm re-documenting my thoughts/design in this area. 
 Watch the pluggable-db branch for new documentation  to appear soon.   
It will be directly web-browsable from the repos.  Dang SVN is cool:-)

And yes it's taking me a while.  I'm making progress again, now that 
I've coughed up *nearly* all of my lungs.  This year I seem to be a 
programming equivalent of a "sick building".

>
>    Having the .svn magic local backup copy of the file would also
>probably be unnecessary in this case as well but I've seen that thread
>go by a few times already . . .  Definitely not a showstopper compared
>to the above subjects . . .
>
Nothing says that you have to check out the whole repos for your working 
copy.

>
>    I hope these numbers don't scare anyone :) . . .
>  
>
Not Me.

Gat


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Getting Lock/Modify/Commit cycle out of SVN

[Ben Collins-Sussman <su...@collab.net>]

seanc@dimensionalrift.com writes:

>     Has anyone tried to coerce SVN into providing a Lock/Modify/Commit
> style?  In order to manipulate large numbers of binary assets properly
> this is necessary, but goes against the SVN's (and CVS's) model of
> update/modify/update/merge/commit.

Indeed it does.  At the last apachecon, a bunch of svn developers came
up with a brainstorm of how we might add this feature someday.  It's
in /trunk/notes/locking-plan.txt.

At a minimum, it would be nice if svn could at least help people
communicate better.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org