non-mainline revision numbers (was The new web interface style)

[John A Meinel]

Goffredo Baroncelli wrote:
> On Wednesday 01 February 2006 14:04, Martin Pool wrote:
>> On 27 Jan 2006, Goffredo Baroncelli <kreijack at alice.it> wrote:
>>
>>>> 2.1 Change the hash in the fillisting view to be the revision number,
>>>> this will make the filelisting view easier to use (since the revision
>>>> number actually have a meaning to the user). 
>>>> So the row:
>>>> -rw-r--r-- hgweb.py ghigo at therra.bhome-20060124230640-d3be84f12d22d486 
>>>> would change to be:
>>>> rw-r--r-- hgweb.py 114
>>> There are some revidion-id without a revno: the merged revisions are without a
>>> revno.... So it is no possible for every case to replace the
>>> revision id with the revno; moreover the revisionid is independent by the
>>> repository; the revno depends by the merging history. For an internet 
>>> user interface, that matters
>> Perhaps we should set an algorithm for assigning something like
>> dotted-decimal numbers to non-mainline revisions.  Since we retain the
>> order of parents for each revision we can do this reproducibly for any
>> given branch.  (Of course the numbers will only be valid within a
>> particular branch.)
>>
>> CVS names non-mainline revisions with a prefix of the revision they
>> branched from.  
>>
>> But for bzr perhaps it would make more sense for revisions to be
>> numbered according to the point where they merge in.  So the revision
>> merged into mainline r69 could be r69.1.50, if it was 50 revisions from
>> the start along *its* mainline.  In the (fairly rare, but supported)
>> case of revisions that merge more than one, it could be r69.2.50.  And
>> so on for things recursively merged in.
>>
>> (Assigning these might be expensive?)
> 
> Why not something like
> 
> xx.yy
> 
> where xx is the revno of the last non merged revision before the "xx.yy" one
> and the yy is the distance between the revision xx and the revision xx.yy in the 
> history. This is simple and unique for every branch, even tough the topography information
> is lost...
> 
> 
> For examples,
> 
> revid			revno		parents
> rev-E 			2		rev-D, rev-B
> rev-D [MERGED]		1.3		rev-C
> rev-C [MERGED]		1.2		rev-A
> rev-B [MERGED]		1.1		rev-A
> rev-A			1		/
> 
> 
> Goffredo

I think it is a nice number, but I don't think it is unique. It might be
unique if you went the other way. But if you look at this tree:

A - B - C - D - E
| \       /   /
|   F - G   /
 \        /
  - H - I

Then the numbers would be:
A 1
B 2
C 3
D 4
E 5
F 1.1
G 1.2
H 1.1
I 1.2

If you number X.Y where X is the branch point, and the Y is their
personal revno, you would end up with:

A 1
B 2
C 3
D 4
E 5
F 1.2
G 1.3
H 1.2
I 1.2

So you would have the same problem. If you make X the number where they
were merged rather than branched you end up with

F 4.2
G 4.3
H 5.2
I 5.3

Which is at least unique. I understand why Martin proposed "X.1.Y",
because you can have multiple revisions merged at once. But since that
is 'supported but not recommended', why not make it so that it only
shows up when necessary. So the first parent gets "XX", the second
parent gets "XX.YY", and then the third parent gets "XX.YY-2".

That gives all revisions a unique number based on the current branch,
and makes them look nice in the general case.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060204/5e7bc4c2/attachment.pgp