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

[Thomas Keller]

Stephen Leake schrieb:
> 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".

Yep, you're right. It was late that day...

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

Right, but this is not so common. Still, the code supports both cases.

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

Currently, it does not. This is, btw., also a difference to mtn clone,
whose target directory always must not exist, otherwise clone bails out
early. In the end after pulling, clone also only does a checkout. So we
could here, for consistency, disallow checkouts in already existing
directories for mtn checkout as well, but I don't know if this bugs
anybody. Probably not so much.

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

"backup" sounds nice.

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

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

I don't hold you here, but I won't have much time supporting your work.
Beside that you're the pro when it comes to conflicts code now ;)

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature