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 [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
Received on 2010-02-14 08:35:00 CET