[MERGE] forward-sorting puts mainline revisions first

[John Arbash Meinel]

Aaron Bentley wrote:
> Hi all,
> 
> This patch changes the sorting done by log --forward (and relatedly,
> pull -v), so that mainline revisions always appear before the merged
> revisions.  e.g.

...

This is very nice, but I think it is incomplete. At each level, the
children should be sorted with their parents. This is actually the same
problem as our 'dir_sorted' issue. Only we don't easily have a prefix
that we can use.

If it isn't clear, this is my idea, if we have a double nested merge,
when we reverse it, we should reverse each chunk separately, and keep it
after the parent.

So if it is currently like this:

9
8
7
 6
 5
  4
  3
2
1

When reversed it should be:

1
2
7
 5
  3
  4
 6
8
9

At least that makes it more consistent. Where the things that were
merged, come after the revision that merged them. And children are in
the same direction as the parents.

I won't block on this, because I really don't like the way 'log --long
--forward' looks. And prefer to see my timeline as oldest at the top.

I think everyone has gotten used to bzr log | less because it is a
crappy output format, which we are maintaining for compatibility with
svn/cvs. Rather than doing something nice and defaulting to log
-r-10..-1 sort of a thing
I think Arch actually got this somewhat right because it had the concept
of 'this branch goes from 1-N'. With bzr, it is harder to figure out
where this branch's 'first revision' is.

I'll +1 you, just to get what you've done. But more as a stopgap than
because I think it is perfect.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060623/e686cd5c/attachment.pgp