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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> A annoyance for me has always been that monotone can't switch to another
> workspace 

I think you mean "switch to another branch/revision in the same workspace".

> if it has to remove directories which are not present in the target
> revision and these directories contain unversioned files (f.e.
> editor backup files). monotone then bails out with "X workspace
> conflicts" and lets the user clean up his mess.

There's a similar problem with "unversioned files".

> So I hacked something together last week or so, for which I want to get
> some feedback. The code resides in nvm.experiment.remove_leftover_files
> and essentially does the following:
> It introduces a new option --move-conflicting-paths for all
> workspace-update related commands (clone, checkout, update,
> merge_into_workspace) which then notices conflicting paths during the
> simulated working tree phase and moves these conflicting paths into
> _MTN/conflicts/DATETIME, where DATETIME is the current date/time stamp
> of the update operation.

Excellent.

Is there really a use case for "checkout into an exisiting workspace"?
I should think mtn would simply refuse to do that.

> A user can then decide to restore them later on (the directory structure
> is preserved) or remove them by rm -rf _MTN/conflicts. I know that the
> naming of the directory currently conflicts with the upcoming conflicts
> work Stephe prepares, but I couldn't think of a better / shorter name.
> Still, suggestions are pretty much welcome. 

How about 'backup'?

Or 'conflicts_tree'.

> I think one could also name directory like the source revision from
> which the user switches from (and name it "base" or something in the
> "checkout into an existing directory case").
>
> I haven't yet written tests for it, which I plan to do when the
> functionality finds support, but documentation is already in place.
>
> Opinions?

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".

I'd really like to refactor the conflicts code; it's crying out for a
base conflicts class with report_stdio, write_basic_io, read_basic_io,
resolve operations. If we are going to be adding workspace conflicts,
we should refactor first.

-- 
-- Stephe