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

[Goffredo Baroncelli]

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

[...]
> 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

-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack_ at _inwind.it>
Key fingerprint = CE3C 7E01 6782 30A3 5B87  87C0 BB86 505C 6B2A CFF9