[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: David Mankin <mankin_at_ants.com>
Date: 2002-04-24 20:23:24 CEST

On Wed, 24 Apr 2002, Brane wrote:
> Karl Fogel wrote:
> >"Bill Tutt" <billtut@microsoft.com> writes:
> >
> >>>I don't agree. Branches are not a "timeless concept of the
> >>>
> >>filesystem".
> >>
> >>Just a finicky point. Branches are very time driven. No part of the
> >>system should be timeless. (i.e. not directly tied to a repository
> >>version number) Copy information certainly is.
> >>
> >
> >I think "timeless" here meant "inherent in the semantics we've promised
> >from our filesystem, regardless of backend implementation", i.e., the
> >opposite of "ephemeral".
> >
> Yea. I was quoting the Ben's proposal. :-)
> >It wasn't related to the fact that repository version numbers are an
> >increasing sequence flowing forward in time.
> >
> >(Unless, of course, by "tied to a repository version number" you were
> >referring to *release* numbers, not revision numbers... Oh, the
> >possibilities for misinterpretation are indeed legion :-) ).
> >
> Unfortunately ...

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

Otherwise, I think this is something to be avoided, since many human-based
pieces of data refer to revision numbers, and they would be confused by a
numbering change. For example, commit logs often refer to revision
numbers (these could conceivably be patched up on restore), and so do
email messages both automated and manually written. And also issue
descriptions. And other places I'm sure I'm forgetting. If revision
numbers change across a repository upgrade/transition (the time we're most
likely to use dump/restore, right?) then we'll end up with a lot of very
hard to understand historical text.

-David Mankin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 24 20:24:43 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.