Dotted revno "algebra"

[Francis J. Lacoste]

I completely agree. 

There is no difference for me between 8564.1.32.1 and 
launchpad at pqm.canonical.com-20100501085755-q23vnwvz5it2xs8v

That's to mean that, if I want to do something with a dotted revision, I'll 
have to find it first in a bzr log output, and then copy it. Because it doesn't 
mean anything to me. 

As this seems to be causing all sorts of performance problem, I'd suggest 
dropping them entirely. Keeping revno on the mainline is nice, but everything 
else could simply use SHA-1 identifier or whatever, and nobody will care... 
really.

-- 
Francis J. Lacoste
francis.lacoste at canonical.com

On May 2, 2010, Martin Pool wrote:
> I think that users see the dotted revnos basically as near-opaque
> tokens for revisions.  They're not inherently useful or meaningful to
> anywhere near the degree that mainline revnos are.  (Even there,
> opinions vary and there are caveats on how you can use them, but the
> ordering relationship is basically useful.)
> 
> If all we need is a handle for a revision, it seems unattractive to me
> to define this in a way that depends on the graph size - even if it's
> a relatively cheap algorithm or it's not the entire graph or it's
> sometimes satisfied from cache.  To me much of this discussion feels
> like microoptimization of something that we know is not a global
> maxima.
> 
> Now in your case 4, we're starting to talk about when the user
> specifically wants to point to a path through the graph, and I can
> definitely see that being useful in some simple cases like "the
> revision merged in by r20" or "the 3rd ancestor of the 2nd parent of
> r20".  (Which is a bit like git's operator grammar for revisions.)
> Perhaps these cases would be the most common ones for wanting to refer
> to non-mainline revisions from the command line, other than pointing
> to them.  You could also want to say "the commit that was r20 on the
> branch nick abcd", though obviously that's not guaranteed to be
> unique.
> 
> > 4) I wonder if we would be better off choosing a more obvious grammar.
> > For example, imagine if a number indicated to more N parents back, and .
> > symbol indicated to move to a right-hand parent. Then the question
> > becomes whether we want to special case the first number, to count up
> > from zero, or to count back from the tip. (is 1 the first commit, or is
> > it last commit.)
> 
> These things are a bit more like searches than original names, in the
> sense that they may not be guaranteed unique (indeed may be N:N) and
> they're not necessarily cheap to calculate for all revisions when eg
> printing a log.  In that case I think you would normally want
> something that is extremely cheap to calculate just from the revision
> id.  At which point I would probably come back to using the revision
> object hash from the current format, which won't be stable across
> revision representation changes, but will be stable across branches,
> and istm that we could both print that and look it up quite cheaply.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100503/a3c8938a/attachment.pgp