monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] WIP: multirevision disapprove and clean workspace f


From: Thomas Keller
Subject: Re: [Monotone-devel] WIP: multirevision disapprove and clean workspace features
Date: Wed, 21 Apr 2010 16:01:38 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.8) Gecko/20100228 SUSE/3.0.3-1.1.1 Lightning/1.0b2pre Thunderbird/3.0.3

Am 21.04.2010 14:53, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
>> Very cool, code looks good and clean. Some minor obvervations:
>>
>> 1) nvm.tkoskine.purge:
>>
>>    We're usually very careful before nuking files in the user's
>>    workspace and this command does all of its beauty without any
>>    "do you really want to do that?!" checking. Maybe it would be
>>    a good idea to implement that and only act on the common global
>>    --non-interactive option automatically?
> 
> Alternately, move the deleted files to _MTN/resolutions if
> --move-conflicting-paths is given, as many other commands do.

I already thought of _MTN/resolutions here, but in a different context:
Also purge whatever is there when mtn purge is called. I don't think
moving stuff away, i.e. out of the eyes of the user, and not caring
about it any longer at all is so good either. We basically move the
problem further with that, because the user forgets about the files in
_MTN/resolutions and we have to handle conflicts which arise when a file
with the same name already exists there, which is quite likely here f.e.
for temporary (ignored) build files.

> I just noticed that the option help for --move-conflicting-paths still
> says _MTN/conflicts; I just fixed that in main.

Ok, thanks!

>>    As a bonus point this could lead to some generic input prompting
>>    code which could be used in other areas as well and replace
>>    hackish implementations there (I particularily remember our
>>    key password prompt here...), i.e. something like this (in
>>    pseudo code):
>>
>>    enum { yes, no, undefined } bool_answer;
>>    user_prompt::ask_yes_no(const string & question, bool_answer & yes)
> 
> Perhaps this could be enhanced to take in the value of --no-interactive,
> and a default answer to return in case that is true.

I also thought about this and then I immediately thought about my
earlier rant of state changing we do in so many places: to handle
--non-interactive we would additionally have to pass an options instance
to the functions it... maybe this is neglectable in this particular case
(some people might even say its good "decoupled" design because it would
ease unit tests we don't currently do at this level), but it still
smells a little for me personally.

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


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]