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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
