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
Received on Wed Apr 2 22:31:40 2003