On Sat, Feb 13, 2010 at 9:56 PM, C. Michael Pilato <cmpilato_at_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  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
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.
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
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).
Received on 2010-02-14 08:35:00 CET