[MERGE/RFC] Dotted-decimal revision numbers in 'bzr log'

Robert Collins robertc at robertcollins.net
Thu Sep 28 07:45:21 BST 2006


On Fri, 2006-09-08 at 10:04 +1000, Martin Pool wrote:
[martins review comments]

I've done these. I'm now working on accepting dotted-decimal input.

AIUI to merge this we need:
 * minimal dotted-decimal input working.
 * decide if the currently implemented dotted-revno numbering is 'ok'.

At the moment there are two mooted choices. Given a revision graph:
G = {
  'A': ['B', 'C']
  'B': ['F', 'D']
  'C': ['E']
  'D': ['E']
  'E': ['F']
  'F': []
}

we currently show this as:
A:3
  C:
B:2
  D:
  E:
F:1


And we can assign branches from the merge point:
 counting from the merge point:
A:3
  C: 3.1.1
B:2
  D: 2.1.1
  E: 2.1.2
F:1

 counting to the merge
A:3
  C: 3.1.1
B:2
  D: 2.1.2
  E: 2.1.1
F:1


or from the branch point:
A:3
  C: 2.1.1
B:2
  D: 1.1.2
  E: 1.1.1
F:1


Assigning branches from the merge point has the following
characteristics:
 * its more work to calculate for an entire graph. (not a huge amount
more, but more). (you need an assignment order that operates in the
reverse order to the postorder traversal that generates the merge sorted
output).
 * the numbers that are assigned within each shown branch have no
relevance to the actual way they were created - consider C for instance,
which was committed on top of E but is assigned to the branch 3.1. So
theres no context beyond the visible where-it-was-merged-into one that
the display also gives you.
 * the numbers assigned will stay short as long as the merge size is
small. Large merges may have many branches come in at once, and the
number of branches needed concurrently will grow to match.
 * assigned numbers are only stable until ghosts are filled or a pull(or
pull overwrite) is done. Merges of a revision into another branch will
change the revisions number.

Whether you count towards or away from the merge this stays the same.

Assigning branches from the branch point has the following
characteristics:
 * Of the two approaches its less work to calculate for an entire graph,
but it will always require calculating [or having cached data about] the
entire graph.
 * The numbers assigned to each revision are based on the origin of the
revision : they provide the origin-of-the-revision rather than the
merged-into-branch data. So the number data is complementary to the user
show layout.
 * long lived branches with many merges into them that serve as the
basis for other branches will over time create deeply nested revision
identifiers. This is resettable by doing a 'pull' or pull --overwrite
into that branch. The occurs because each branch-point needs a number
assigned to it for disambiguation.
 * assigned numbers are only stable until ghosts are filled or a pull or
pull --overwrite is done. merges of a revision into another branch will
not change its number if the other branch has the same basis history
(i.e. no more or less ghosts) and there are no extra branches with the
same branch point as this revisions in the merged-into branch. That
means that the merge of a recent branch will often preserve the revnos
of the merged-from branch revisions [except for its mainline ;)], but a
merge of a long lived branch may well change them.

My preference is for the assign-from-branch approach because of the
greater stability. (stability across merges means they can usually be
used across merges).

 * Decide if the performance hit (about 15% ?) if acceptable.
        
        > So there is a performance hit. 70ms of real time, 10% of total
        execution
        > time. Whats the verdict ? 
        
        Well, even if merge_sort scales O(n), a hit of 100ms on 10,000
        revisions
        is probably tolerable.  But I'd really like to have a version of
        merge_sort (and therefore, the new revnos) that scaled with the
        log
        range, not the size of the graph-to-origin.
        

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060928/5ea72685/attachment.pgp 


More information about the bazaar mailing list