[Monotone-devel] workspace merge status update

[Zack Weinberg]

It's been a while, but I'm back on the trail of workspace merge.
Summer of Code is formally over at this point, but UCSD doesn't start
back up until late September, so I intend to keep working until then.
(I probably won't have time after classes start, but you never know.)

I've made some but not all of the changes Nathaniel requested to the
.migration branch.  The big remaining lack is that testing still
doesn't work the way he wanted (mainly because I am having no luck
figuring out how to do that).  Furthermore, I noticed that contrary to
the docs, file-content-change entries _can_ show up in _MTN/revision
under some conditions; I think this is harmless, but we might want to
think about whether or not to prevent it.

More interesting is nvm.workspace-merge.noconflict, where there is a
new command, explicit_merge_and_update.  This does exactly the same
thing as explicit_merge, except that instead of committing the merge
to a specified branch, it updates the current workspace with the
result of the merge.  It does NOT give you conflicts in the updated
workspace; you have to resolve all conflicts during the operation,
just as you do for normal explicit_merge.  The idea is to get this
working, use it to find and fix all 'fallout' bugs from the rest of
monotone not being set up for multi-parent worspaces, and then go on
to conflict resolution in the workspace.  The command is not intended
to survive under that name, but by having it off on the side like
that, we make the branch mergeable at any point -- everything
continues to work as it is today, unless you go and use the special
command.

There is a lot of fallout.  Right now, just about every command that
operates on a workspace will throw an invariant failure if applied to
a workspace that's the result of explicit_merge_and_update.  I mean to
fix these incrementally.

There is also a peculiar bug where the merge result, as seen in the
workspace, is not always the same as what you'd get from
explicit_merge followed by update.  What appears to be happening is,
if the workspace is the same as one side of the merge for a given file
(even if that file is unmodified in the workspace), the changes from
one side -- I'm not sure which side -- get lost.  If the workspace
revision is the ancestral revision, this does not happen.  I haven't
tried setting it to something uninvolved.  I could use some help
debugging this.

I'm going to be out for the next several hours but will be back in the evening.

zw