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

[Stephen Leake]

"Zbigniew Zagórski" <address@hidden> writes:

> 2008/9/21 Thomas Keller <address@hidden>:
>>
>> Hi all!
>>
>> A annoyance for me has always been that monotone can't switch to another
>> 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.
>
> Random idea related to topic: Maybe monotone could delete ignorable
> files/folders? This would solve your problem in more pragmatic way -
> no other options needed, just correct .mtn-ignore file.

The overwhelming majority of ignored files in my typical workspaces
are object and exectables. They take significant time to create
(hours), so I don't want them deleted by mtn.

> Current behaviour is just strict implementation of "no data loss"
> paradigm. Question is:
>
>     Are ignorable files the same as "not important"?

No.

>> 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.
>> ...
>
> If answer to above is no then it's the only reasonable solution.

We could provide detailed conflict resolutions, as is now being done
for the merge conflicts; see n.v.m.resolve_conflicts.

> BTW. This command is *reliable version of:
>
>     mtn ls unknown | xargs mv --target-directory=$ROOT/_MTN/conflicts/$(date)
>
> *reliable means - no name conflicts and no problems with whitespace in names.
>
> Am I right?

no, because --move-conflicting-paths moves _only_ the paths that
actually cause conflicts (at least, I hope that's what it does);
that's not the same as all unknowns.

-- 
-- Stephe