On Sat, Feb 13, 2010 at 9:56 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > You can't think how that would handle those actions because many of them > won't be handled at all. 'cp -a wc1 wc2' will result in a non-working-copy > named 'wc2'. 'mv wc1/trunk .; rm -rf wc1' will result in a non-working-copy > named 'trunk'. And so on. There's been talk of adding 'svn' tool support > for these actions, of course, but I don't know if the details have been > decided upon. > > Why don't you chime in over on dev@, since that's rather the place to > discuss Subversion's development?
That's probably redundant--I'm sure all of this is being thought of, but I'll summarize what comes to mind, just in case. Based on looking through [1] some more, it looks like "cp -a wc1 wc2" and renaming working copies should work fine, since the database is inside the working copy, and will just get copied along with the rest. (That's the only place I could imagine a working-copy-global database going anyway, else there would be endless problems with finding the database over NFS and in shared directories, knowing when to purge old databases, etc.) Hopefully there'll still be a way to slice out a piece of a repository ("mv wc1/trunk .; rm -rf wc1"), which wouldn't work if it's dependent on a global db at the top. [1] http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design And the other part from the earlier mail: > Putting text-base in Sqlite would be unfortunate. One of the great > things that could be done with the current format would be to support > COW filesystems, which are under active development and hopefully will > be fairly common in a few years. That would eliminate the 2x data > overhead, while still supporting client-side diffs. I'm not sure that > Sqlite is any good at storing large, changing files, either (database > fragmentation). I have a few gigs of ~5 meg files in Subversion, and the idea of storing large blocks of data in SQLite is a bit scary; I don't think it's designed for blobs that size. Anything that lumps files together like this is effectively subjected to two layers of fragmentation instead of one (filesystem + db). I'm very happy to see the beginnings of svn obliterate support. I brought that up quite a while back, but people at the time seemed certain that there's never a need to remove old data (which I've had to do many times on our CVS repositories due to disk space limits and prevented us from using Subversion for a long time). -- Glenn Maynard