"hg up -C" is also evil - ;-)

[Steve Borho]

On Fri, Nov 5, 2010 at 10:13 AM, Waldemar <waldemar at beechwoods.com> wrote:
> On 11/05/2010 07:55 AM, Kevin Bullock wrote:
>> On 5 Nov 2010, at 7:12 AM, Marko Käning wrote:
>>
>>
>>> Yesterday I issued the command
>>>
>>>      $ hg up -C
>>>
>>> actually believing that local changes would be moved into *.orig prior to
>>> the clean update of my working copy.
>>>
>>> But I was wrong! In many other cases local changes will be preserved with
>>> *.orig files or additional warning messages will be thrown, but obviously
>>> not with a clean update...
>>>
>> -C == --clean, which would indicate to me that any uncommitted work will at least be at _risk_ of disappearing. It would seem to make sense to write *.orig files though.
>>
>> pacem in terris / mir / shanti / salaam / heiwa
>> Kevin R. Bullock
>>
>
> I think what's missing is a really solid integration with "shelve".   In
> case of hg update, working directory should ideally be stored in some
> orderly manner with a chance of quick restoration with a single
> command.  For me it's the "third level" of source control. After
> traditional versioning, mq patches, this would be workdir management.

To duplicate shelve, it would be sufficient to have aliases for: hg
diff --git > .hg/shelve ; hg import --no-commit .hg/shelve

but this is not safe in case there are conflicts.  hg update does use
Mercurial's merge and resolve features, so what I've done in
TortoiseHg 2.0 is to take advantage of this work-flow.  The update
tool does:

hg update -r REV --tool internal:fail

This will update like normal but if the revision you are updating to
modifies files where you have uncommitted changes, it marks those
files as needing resolve.  THG launches its resolve dialog if the
update marked any files unresolved.

http://cdn.bitbucket.org/tortoisehg/thg/downloads/resolve.PNG

We also use this methodology for merging and rebasing: mark
conflicting files as unresolved, then allow the user to resolve the
conflicts at their leisure using the resolve dialog, restarting each
file merge as many times as they like until they get them right.

> In case of purge, it should just do what it says: purge.  I find purge
> extremely useful when debugging builds.  It gets rid of transient files
> and allows me to rerun makefiles with confidence.

No doubt.  I've given TortoiseHg 2.0 a purge dialog with progress bars
and options for preserving .hg* files, etc.  It's an efficient 'make
really-clean'

-- 
Steve Borho