Re: revnum (still) considered harmful

On Mon, 2002-12-16 at 16:29, Tom Lord wrote:
> (a) the (much reduced) performance limitation:

I'm not sure how your hypothetical distributed repository is going to
determine that transactions are non-overlapping more cheaply than it can
settle revision numbers. But you've admitted this is a small issue.

> So, I think that both the intra-repository and global revision names
> for merging purposes should not be based on revnum, but on an
> independent, higher-level namespace.

Well, here's how I think we'd implement this if we were going to:

  * Commits would acquire an optional parameter for the revision name.

  * The revisions table would contain mappings from names as well as
revnums. (A revnum would map to ("revision" TXN NAME); a name would map
to ("revision" TXN REVNUM). Or maybe they'd both map to the identical
skel containing both. Doesn't matter much.

  * Revision specifications could be given as names as well as the
current options (numbers, dates, HEAD, etc.). An ra method for
get-named-rev would be needed alongside get-latest-rev and
get-dated-rev. And possibly a method to get the name given the number,
given the next step.

  * When it comes time to store merge history, use <guid,name> tuples
instead of <guid,number> tuples.

I don't really like this idea because:

  * Ignoring the merge history aspects, it feels like window dressing.

  * I don't really buy that smart merging between different pieces of
revision control software is a realistic or desirable goal. And even if
it does come about, using numbers doesn't mean we can't interoperate; it
just means that our revision names are less informative.

  * You can no longer compress merge history using revision ranges (or
if you do, you lose the benefit of making the merge history readable).
I'm already concerned about the bulk of merge history information given
that we may get stuck storing it for each file.

At any rate, it's most likely pointless to try to design a merge history
system right now, given that no one is planning to implement it in the
immediate future (as far as I know). So this conversation probably
shouldn't go on too much longer.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 16 23:40:37 2002