On Wed, Apr 24, 2002 at 09:09:39PM +0200, Branko Äibej wrote:
> Ben Collins-Sussman wrote:
> >Branko Cibej <brane@xbc.nu> writes:
>...
> >>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.
Why messy? The load process is simply loading trees into the repository.
The whole 'copy by ref' thing occurs within the dumped data, but it
certainly is wholly independent. Thus, if other data exists within the
repository, then why should the load process care?
> >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.
The first rev in my dumped data is going to contain full texts of
everything. Those are simply the new contents for the files as they get
loaded. Sure, this is kind of a "merge" process, in the sense that
directories of files are combined, but you aren't going to get true merge
conflicts. The loaded files are target full-texts, *replacing* anything that
previously existed on the path.
> >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
> >now...
I think it *could* be nasty to dump a subtree (e.g. "/trunk"), but it could
be done(*). I'd simply recommend that dump operates on "/" for now.
However, on the load, there is *no problem* if you insert a path prefix for
the loaded tree. It is totally reasonable to take all the incoming-paths
from the dumped data and prefix "/loaded-2002.04.24" onto the front, so that
you get "/loaded-2002.04.24/trunk/foo". After the load, somebody could
rearrange HEAD however they want, and keep all the history in the loaded
area.
I believe you'll find this "prefix" feature very easy to do :-)
> 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
Let's please call it dump/load. I don't see this as a "restore"; it is
definitely not restrained to restoring a repository. In fact, I think you
would have to actively encode restrictions to force it to be restore-only.
> this to the case where there are no filename conflicts, but it *would*
> change the revision numbers.
Yes. But note that filename conflicts aren't truly a problem for the load
process. The resulting repository could be ugly, sure, but the load process
won't care one whit. You have a new fulltext arriving; you overwrite; no
problem.
> The other use case is this: you create two sepearate dumps of the same repo
Sure.
> 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.
Nope. That won't recreate the repo. You'll lose all references across the
dumped data boundaries. The second dump will produce fulltexts for
everything at rev 1001. All future rev trees will refer to those. Nothing
will be able to refer to rev 0..1000; otherwise, your dumped data will be
internally-inconsistent and/or missing some fulltexts.
Cheers,
-g
(*) I think this depends upon the algorithm used; if you're just sequencing
through revision trees, then you could simply start scanning the tree at
an arbitrary path. I think the problem will occur when you have a copy that
references something "outside" of that path; basically, you'd lose the
notion of the copy and pretend the original started at that point in the
rev/path tree. Because of these extra checks, it could make using a
dump-start-point a bit tricker than if you simply said "always dump /".
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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:53:24 2002