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

[John A Meinel]

Goffredo Baroncelli wrote:
> On Saturday 04 February 2006 18:48, you (John A Meinel) wrote:
>> Goffredo Baroncelli wrote:
> [...]
>>> 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 is unique for a given history; my number scheme is generated by a 
> function like
> 
> def history_to_revno_mergeno(history):
> 	revno=0
> 	mergeno=0
> 	for r in history:
> 		if r is a merged revision:
> 			mergeno+=1
> 		else:
> 			mergeno=0
> 			revno+=1
> 		yield revno, mergeno
> 
> On the basis of the code above, it is clear that my number scheme is unique
> 

You are correct. Your method does generate unique numbers for every
revision. But it isn't stable, and relies purely on the order that you
find them. And "get_ancestry()" isn't even guaranteed to be sorted
correctly. (In fact, it passes a set() which ensures that sorting is lost).

I'm not sure about your sorting for "history".

> [...]
>> 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.
> 
> On the basis that every proposed number scheme is unique, I don't understand 
> which is the gain to use a more complex number scheme like x.y-z....
> 
> Yes, it could be useful to generate a number scheme where the first number
> is the revno where the revisiomn is merged, but there is the problem of a
> revision merged in two revision...
>  
>> John
>> =:->
> Goffredo
> 

The advantage of a different scheme is stability. If I merge a new
revision into jam-integration, it would be nice if all of my short
revnos stayed the same. (which is why you have to number from the merge
point which is fixed, not the branch point, which can have an infinite
number of branches that you don't know about yet).

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/20060206/87c300ac/attachment.pgp