monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] conflict messages


From: Derek Scherger
Subject: [Monotone-devel] conflict messages
Date: Sun, 09 Dec 2007 13:05:05 -0700
User-agent: Thunderbird 2.0.0.9 (X11/20071116)

I'm mostly finished with the cleanup of non-content conflict messages
I've been working on lately. Here are some samples from the output of
tests/conflict_messages on the
net.venge.monotone.cleanup.conflict-messages branch. These mostly follow
the suggestions Zack had to my earlier email.

mtn: [left]  30ff3975abe7cba4c968da0f8828e4d03c141dd0
mtn: [right] 69975df3b04f9033828c2926da663ce3c2fc7a5d
mtn: conflict: missing root directory
mtn: directory 'foo' pivoted to root on the left
mtn: directory 'foo' deleted on the right

mtn: [left]  e0989b71cffd43035921ff1b52ba07371a00895b
mtn: [right] 30329f0b5641abac57a0fce1619cb3b23fe4eac2
mtn: conflict: invalid name _MTN in root directory
mtn: 'foo' pivoted to root on the left
mtn: 'foo/_MTN' added in revision
30329f0b5641abac57a0fce1619cb3b23fe4eac2 on the right

mtn: [left]  7b6b5708801eff7f64cbf866989d35ea0402a812
mtn: [right] 559bfd7d3fe34bc6272f888f5bb785529fef7ea2
mtn: conflict: directory loop created
mtn: 'foo' renamed to 'bar/foo' on the left
mtn: 'bar' renamed to 'foo/bar' on the right

mtn: [left]  0a7278752c48d094743d60dda802843fc4ffc5e4
mtn: [right] bcf4b35578f6fa25111594df8351833fed0b682d
mtn: conflict: orphaned file 'foo/bar' from revision
9b967a93a9da47c9059e3a1deef0126f2b3123f2
mtn: parent directory 'foo' was deleted on the right
mtn: file 'foo/baz' was added on the left

mtn: [left]  4b27a8d3f26a70f1df727b2c6003d22d50a5f156
mtn: [right] eb0e92676325c07ef6d18dc02c12bb892569fa46
mtn: conflict: multiple names for file 'foo' from revision
78d3858c792c04175a2ddfffec939f844a15973c
mtn: renamed to 'bar' on the left
mtn: renamed to 'baz' on the right

mtn: [left]  312c6ef90e9ed514f28b72b5926fe466c6a9468a
mtn: [right] 0442b661dbd5dd18f5ed43b07138bade830bb169
mtn: conflict: duplicate name 'bar'
mtn: added as a new file on the left
mtn: added as a new file on the right

mtn: [left]  0871050c24bdcaaee2ba8bee3a5821c8e201b088
mtn: [right] f07a57a016abe9997b27539824df36f0db42b441
mtn: conflict: multiple values for attribute 'attr1' on file 'foo'
mtn: set to 'valueX' on the left
mtn: set to 'valueZ' on the right
mtn: conflict: multiple values for attribute 'attr2' on file 'foo'
mtn: set to 'valueY' on the left
mtn: deleted on the right

mtn: [left]  bc12c73c56eb29876c49e588344920b08e723a44
mtn: [right] fcf6894e6bf1b25299f10470be33fc80c555be6c
mtn: conflict: content conflict on file 'foo'
mtn: content hash is f1bb6fff2ad16d67143d89fc374ede7abec5d437 on the left
mtn: content hash is b966b2d35b99e456cb0c55e4573ef0b1b155b4a9 on the right

I've changed the show_conflicts command to use the same machinery
which means it outputs much more detail than it does on mainline at the
moment. I assume this is a Good Thing (TM) but if anyone really likes
just knowing the number of conflicts of each type, now would be a good
time to speak up. One thing to note is that show_conflicts reports
content conflicts for files that may very well resolve cleanly with the
internal merger so things might look a little more scary than they need too.

I've also changed the way we handle content conflicts in
resolve_merge_conflicts by running two separate passes. The first pass
runs only the internal merger. Once this is done, all remaining content
conflicts are reported as above and then a second pass that runs only
the user merger (lua hook) runs to deal with the real conflicts.

The following few revisions are the more interesting ones in all of
this, and could use a bit of scrutiny just to make sure I'm not doing
anything silly.

ab21ddc7 - makes some changes to roster_merge, assign_name and
copy_node_forward in roster_merge.cc to get left and right nids from
what were previously nid1/nid2 so that we can say "on the left" and "on
the right" reliably in the messages above.

80a51a99 - adds the right marking map to content_merge_database_adaptor
to be able to get files born after the lca on either side.

3e61a21f - adds a roster cache and marking maps to the
content_merge_workspace_adapter used for looking up the workspace roster
and the new "to" roster in the pluck case and adds a new simplified
content_merge_checkout_adapter for checkout and clone

dab5af5f - splits resolve_merge_conflicts into two separate passes, an
auto merge pass followed by a user merge pass over the remaining conflicts.

Cheers,
Derek





reply via email to

[Prev in Thread] Current Thread [Next in Thread]