[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: Greg Stein <gstein_at_lyra.org>
Date: 2002-04-24 21:39:55 CEST

On Wed, Apr 24, 2002 at 08:47:03PM +0200, Branko ─ibej wrote:
> Ben Collins-Sussman wrote:
> >David Mankin <mankin@ants.com> writes:
> >
> >>I'm not sure I fully understood the proposal, but what I think I'm picking
> >>up from the discussion is that the revision numbers (e.g. rev 1770) would
> >>not be maintained across a dump/restore. If I'm wrong, good. Just let me
> >>know.
> >
> >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.)

Agreed. I see no reason to *prevent* their numbers from changing. To me, it
is entirely reasonable to do something like this:

$ svnadmin create ~/repos/new
$ svnadmin dump -r1000:HEAD ~/repos/project | svnadmin load ~/repos/new

The above pair of commands effectively trims revs 0..999 out of my
repository. What was rev 1000 now becomes rev 1 in my new repository.

The dump format would contain and ordered sequence of revisions, but there
isn't a need to record their number, except implicitly.

If we use a rfc822 style format, then a header such as:

Original-Revision: 1000

Could be added, but would be ignored on the 'load' portion, since that would
number them, as appropriate, for whatever was already in the repository.


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:40:21 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.