May I suggest that we not worry too much about reloading into
non-empty repositories right now? While it's clear that it can be
done, and that no unresolvable issues come up, it may (or may not)
be significantly more complex to implement.
I'm not saying never do it, I'm just saying don't prioritize it. We
need the dumper/loader first to dump an entire repository and recreate
it in the wake of a db format change. Fancier features are not
necessary right now.
In practice, it will be easy to implement dump/load such that we get
this necessary featureset first while not precluding the more general
functionality of merging revision ranges from one repository to
another non-empty repository. We can keep this in mind while coding,
even though we may not complete that feature for our own migration.
It doesn't affect the dump format a whit. If we preserve the original
revision numbers in the format, we can map them onto any revision
range in the dest repository if necessary. And of course, the dump
format has to be self-contained: it won't depend on external base
fulltexts. Diffy storage in the repository is an implementation
detail. The "real" content of a node is its fulltext, and that will
be retrievable from the dump without reference to any repository.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 22:59:17 2002