[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fs dump/restore proposal

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-04-24 21:09:39 CEST

Ben Collins-Sussman wrote:

>Branko Čibej <brane@xbc.nu> writes:
>>>No, revisions numbers will never change. But the secret, internal
>>>equivalent of inode-numbers will definitely change. No working copy
>>>or human should be able to tell, however.
>>What if you import a dump into a non-empty repository? (Sure, you have
>>to know what you're doing, but I wouldn't rule out the possibility.)
>What does that mean? That sounds horribly messy.
>A dump represents some subset of a repository. I can't imagine what a
>mess it would be to somehow "concatenate" N revisions from one
>repository onto the end of another.
>My (simple) vision was that a dumpfile was a snapshot of a repository,
>and it can be used to recreate the repository. Once we start talking
>about mixing-and-matching pieces of repositories, we're off in another
>world of problems. And I'm not sure that world is important right

Let's say you have a repository that contains projects (top-level
directories) A and B, and another one that contains C. If we allow this,
you could merge the two repositories using dump/restore. Sure, I'd limit
this to the case where there are no filename conflicts, but it *would*
change the revision numbers.

The other use case is this: you create two sepearate dumps of the same repo

    svnadmin dump -r :1000 repo
    svnadmin dump -r 1001: repo

If you want to recreate the repo, you'll have to import the two dumps
one after the other. Although, in this case, revision numbers typically
wouldn't change.

(heh, and he thought it would be easy. :-)

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 21:11:05 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.