Alan Barrett wrote:
> Yes, that's what it means, except that I think it's possible for other
> unrelated new revisions to be added to the repository while the load is
> in progress. If that happens (presumably because somebody else did a
> commit while you were waiting for the load to complete), then the
> revision number offset will not be constant.
It would be incumbent upon the admin to curtail or block commits to the
repository during svnadmin load, definitely.
> Also remember that properties might contain references to version
> numbers. AFAIK svn:externals is the only such property used by
> subversion itself, but add on tools might have their own properties that
> would be adversely affected by changes in revision numbering.
I haven't looked at a dump file format closely enough, but I wonder if
such occurrences might be grep-able, and possibly substituted by the rev
number + the known constant. Continuing on with a repository merged in
this way would be insanity unless you had a way of checking correctness,
though.
A tool to fix up one or more dump files in preparation for merged
repositories in the most practical safe way would be invaluable.
The dream tool would be something that could weave revisions in sequence
by timestamp, incrementing the revision counter and substituting
occurrences in the one or more dumpfiles as it goes. That capability would
have huge implications for individual users and for open source projects
that merge or split over time, but would like to keep their repository
history.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 1 00:32:33 2006