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
Received on Wed Apr 2 21:17:38 2003