Re: [Monotone-devel] [RFC] move unversioned files out of the way

[Stephen Leake]

Thomas Keller <address@hidden> writes:

>> Another way to handle these files is to add support for workspace
>> conflict resolutions. Since you've gone thru the code, how hard would
>> it be to add conflicts for these cases, and then add resolutions for
>> them? For "conflict with unversioned file" the typical resolution
>> would be "merge"; for "leftover path" it would be either "keep" or
>> "delete". Or maybe "rename and merge".
>
> The problem here is that these files are nowhere attached to a manifest
> / revision, so without looking further into the appropriate code I guess
> what has to happen in this case here at first is that these conflicting
> unversioned files get "first class citizens" for monotone, f.e. by
> adding them to the current workspace manifest. Then the "normal"
> workspace conflict resolution machinery (once it is in place) could run
> from there. But then again, I don't know if people want to get
> conflicting unversioned files added to their workspaces silently...

I agree doing things silently is bad.

In order to (usefully) record a conflict, we need to record enough
information to allow resolving it.

In this case, the workspace path to the conflicting unversioned file,
and the nid of the conflicting versioned file, should be sufficient.
That would allow moving or merging at the user's choice.

The other issue is _where_ to record it. At the moment all conflicts
are recorded in a roster_merge_result object. There is one of those
present in CMD(update). 

However, in your current code, these workspace conflicts are
discovered in work::perform_content_update, which is run _after_ all
the conflicts in the roster_merge_result object are already resolved.

So either we need a way to discover these conflicts earlier, or we
need another place to record conflicts, and another function for
resolving them.

The place could simply be a structure internal to
work::perform_content_update; "conflicting_paths" is a start on that
structure, and 'move_conflicting_paths_into_bookkeeping' is a start on
the resolution function.

I think it makes sense to keep workspace conflicts separate from
roster conflicts. roster conflict resolutions are recorded in the
merge result revision in the database; workspace conflict resolutions
should affect only the workspace and/or its manifest.

Hmm. That would mean we need two conflicts files; one for roster
conflicts (_MTN/conflicts_roster), one for workspace
(_MTN/conflicts_workspace). Which would solve your directory name
problem :).

It also means we don't need to refactor the roster conflicts code to
start adding workspace conflicts resolutions; let's just make the
workspace conflict code better in the first place.

Perhaps '--move-conflicting-paths' should be replaced by
'--resolve-conflicts'? 

> I won't have much time supporting your work.

Actually, I think you are supporting it by extending into workspace
conflict resolutions :)

I think I should change the default conflicts file name to
conflicts_roster (unless someone can suggest a better name), in
anticipation of conflicts_workspace.

Hmm. How does this affect the resolution command syntax? Currently, we
have:

conflicts resolve_first user

where the conflicts file _MTN/conflicts is implied. If we have a
choice of files, do we require that the user specify it? Or work thru
_MTN/conflicts_roster first, then _MTN/conflicts_workspace.

Hmm. CMD(update) won't run work.perform_content_update until there are
no roster conflicts. So we need to build an acceptable
_MTN/conflicts_roster first, then start working on
_MTN/conflicts_workspace. So I think 'conflicts resolve_first' should
work on the two files in that order.

Which means 'conflicts store' will have to behave similarly; don't
look for workspace conflicts unless the roster conflicts are all
resolved.

If you don't feel you have time to implement this fully, I think
--move-conflicting-paths is a reasonable addition in its current form.

I've added a simple test for --move-conflicting-paths;
tests/move_conflicting_unversioned. I needed it to drive the debugger
to find out when things were called :).

-- 
-- Stephe