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

Goffredo Baroncelli kreijack at alice.it
Fri Feb 3 12:49:43 GMT 2006


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




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




More information about the bazaar mailing list