[MERGE/RFC] Add dotted-decimal revision numbers to merge_sorted output

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Wed, 2006-09-06 at 22:43 -0500, John Arbash Meinel wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
> 
> 
>> Actually, I always thought they were based on the source. And I thought
>> that is what I just outlined.
> 
> We discussed lying and counting from the merge point but pretending it
> was from the revision before. Anyhow, we seem
> 
>> I think numbering off of the ancestor works just fine, and gives very
>> reasonable numbers.
> 
> to be in agreement now.

Well, after exploring the ancestry, we may need to think about it a bit.


> With this patch:
> python -m timeit -s 'from bzrlib.tsort import merge_sort; import
> bzrlib.branch; import bzrlib.plugin;bzrlib.plugin.load_plugins(); b =
> bzrlib.branch.Branch.open("."); tip = b.last_revision(); g =
> b.repository.get_revision_graph(tip); ' 'sorted = list(merge_sort(g,
> tip, generate_revno=True))'
> 10 loops, best of 3: 250 msec per loop
> 
> 250/172=1.4534883720
> 
> So its going to add 50% to the call time to merge_sort.
> 
> This is probably fixable to a large degree: removing the backwards
> compatability option saves a few ms, we might be able to save a parent
> lookup with some care.
> 
> However, at the real world level, log is not fast enough to be affected
> by this : log in a branch with 7K revisions is several orders of
> magnitude slower than 80ms.
> 
> Rob
> 

Well, the problem is if we start supporting dotted revnos, we have to go
through merge sorted to find them. So it starts adding the expense to
lots of operations. And more importantly you have to wait for merge sort
to finish before you can start logging anything. Which effects the time
to first log. Or even the 'bzr log -r-10..-1' time.

If you could do it incrementally, we would be better off for some
operations. But then we have issues that we have discussed in the past
about anything that doesn't look at the whole ancestry.

Another thing is that technically we could record the revno along with
the commit (since it is only defined as the length of the left-hand
ancestry). Now, ghosts destroy it, but new branches don't have ghosts.

Just some thoughts.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE/6yOJdeBCYSNAAMRAqaxAJ9I9lon+nNEkjymkv6W4F+MIlT9FACfdQM/
H1Y4AHJz+a0nBsA4g457fG0=
=N9lH
-----END PGP SIGNATURE-----