[PATCH] more work on merge

[Robert Collins]

On Sun, 2005-07-10 at 12:13 -0500, John A Meinel wrote:
...
> I can't say it does the best for crossed history, and it still suffers
> from a simple patch applied late causing a shortcut history.
> I suppose a different possibility is to track all distances to a
> revision, rather than just the shortest one, but that does imply having
> to trace all routes through history.
> 
> Otherwise you could do some sort of "average" distance, rather than
> minimum distance.

In a similar theme to my other mail : what makes minimum-path-to-a-node
a better cost than longest-path-to-a-node.

Funny thing about writing emails, it gets one thinking.

Heres a proposal to determine the cost of a path traversal : number of
changes. This allows full SPF to be used rather than breadthfirst, and
will give much better results IMO.

Number of changes could be estimated by Modified-Files + 1/2 New files +
1/2 deleted files. This is absolutely crude, but would favour commits
that only add or delete files over ones that modified files.

A better one (but not one cheaply accessible to baz today - tho it may
be cheap for bzr today) might be lines modified + new files + deleted
files.

This neatly fixes the history shortcut problem. (The late merge produces
a very large LOC change from the merge source to the branch, making that
node an expensive one to take - though it may well be taken once the
mainlines overlapping changes to single lines/files start to dominate).

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: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050711/0355b2e1/attachment.pgp