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

[John A Meinel]

Goffredo Baroncelli wrote:
> On Monday 06 February 2006 15:35, you (John A Meinel) wrote:
>> 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".
> [...] 
>> 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).
>>
> 
> Consider the example below:
> 
>    Branch#1   Branch"   Branch3           Branch0
> 
>                                             Rev-A
>                                               |
>                 /--------------------<--------+
>                 |                             |
>                 v                             |
>       /---------+---------\                   V
>       |         |         |                   |
>       v         v         v                   |
>      rev-B    rev-C      rev-D                |
>       |        |          |                   |
>       +-<------+          |                   |
>       |        |          |                   |
>       |        \--------->+                   V
>       |                   |                   |
>       v                   v                   |
>       |                   |                   |
>      rev-E               rev-F                |
>       |                   |                   |
>       |                   \---------------->--+           
>       |                                       |
>       |                                     rev-K
>       \                                       |
>        \                                      V
>         \---------------------------------->--+
>                                               |
>                                               V
>                                              rev-G
> 
> History at the end for every branch (rev-id:rev-no)
> 
>      rev-A:0   rev-A:0   rev-A:0             rev-A:0
>      rev-B:1   rev-C:1   rev-D:1             rev-D:0.1
>      rev-C:1.1           rev-C:1.1           rev-C:0.2
>      rev-E:2             rev-F:2             rev-D:0.3
>                                              rev-K:1
>                                              rev-B:1.1
>                                              rev-E:1.2
>                                              rev-G:2
> 
> 
> 
>                                         
> 
> Three branches ( Branch1..Branch3 ) are derived from Branch0.
> Both Branch1 and Branch3 merge from Branch2 the revision rev-C.
> Then Branch1 and Branch3 are merged in Branch0.
> When Branch1 and Branch2 are merged in Branch0, the revno 
> ( in branch0 ) of rev-C depend by the merging order. Doesn't 
> matter what is the revno of rev-E, what matters is that
> 1) the revno of rev-E depends by the merging history
> 2) in general the revno isn't equal to the one before the
> merge
> 
> In general the revno stability are guarantee only in a specific branch
> and not across merges. I don't understand what changes if I start the
> revno from the branching or from the mergeing: there are case of
> multiple merge or multiple branch where there are both the possibility that
> the revno is the same or the revno is different.
> 
> My number scheme has the advantage of the simplicity of the code. This is
> the only reason why I proposed it.

It definitely has that. :)

> 
> It is possible that I don't understood very well your number scheme, so 
> please repeat me ( with code if possible ) if I misunderstood it.
> 
> Goffredo
> 

The issue with your version, is that it has some sort of sorting (random
perhaps), which means that numbers which have already been assigned are
subject to change because of future actions.

Here is a small example:

A - B - C - D
  \   /
    E

At this point, with your code the numbering is obviously:

A-1, B-2, C-3, D-4, E-1.1

But if I add a new branch
A - B - C - D - F
| \   /      /
\   E      /
 \       /
  G - - H

Now it depends on how E, G, H are sorted. Say you sorted by alphabetical
revision id, then obviously G could come before E. Say you sorted by
time, but G was actually created *before* E, it just hadn't been merged yet.

All of these are valid under your numbering system:
E-1.1, G-1.2, H-1.3
Or
E-1.3, G-1.1, H-1.2

Which means that the numbers for revisions which haven't changed, are
changing because of new information.

You can always branch off of an old revision. Which is why it isn't a
stable point to number from. But you can't merge more revisions into an
old revision. 'C' will always have parents of B & E, never any more. But
'A' can always have a new child.

My proposal was to give *unique and stable* revision numbers to all of
the ancestry. So that within the context of a branch, the revision
number "5.22" uniquely defines a revision.

The reason for the '1.33-2' is to handle the very rare case of having
more than 2 parents. (The bzr interface is unhappy to do it, requiring
you to use --force) We support it, but believe it isn't a good workflow,
so we discourage it.

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/20060210/05519834/attachment.pgp