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

[Goffredo Baroncelli]

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 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

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