non-mainline revision numbers (was The new web interface style)
John Arbash Meinel
john at arbash-meinel.com
Wed Feb 1 14:01:43 GMT 2006
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?)
>
> Just floating the idea...
>
Well, if we have finally decided that 'pull' overwrites the history,
rather than just taking revisions onto the end. Then we have the
situation that there is a unique revno for every revision. The distance
from it to the Null revision along its primary ancestors.
Which means that at commit time, we can actually add that to the
revision information.
I've thought about doing that for a while, I just haven't decided if it
is worth anything.
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060201/8c3dcdc6/attachment.pgp
More information about the bazaar
mailing list