Re: [Monotone-devel] to be recursive or non-recursive that is the question

[Thomas Keller]

Am 10.05.10 14:37, schrieb Stephen Leake:
> One solution would be for 'revert' to move clobbered files to
> _MTN/resolutions if --move-conflicting-files is given, as update does.

I think not having --move-conflicting-paths here is a completly
different issue and could arise for any implementation of revert.
Stephe, could you file a bug or alternatively add an xfailed test for
that? I think we should handle that some time in the future.

> Better would be to have an option 'revert --exclude-changed-files' that
> would only revert files that are actually gone (because they were
> accidently deleted).

This is similar to what Derek proposed in the other mail, giving options
to revert of what should actually be reverted. But this sounds rather
hard to implement and we should elaborate if this is really a often
needed use case. Way more often should be the use case "revert parts of
patch hunks of individual files" like git does, but we're missing a
staging area for that purpose. Completely different topic :)

>> Recovering from (2) is ... not so easy. If you happen to have all the
>> reverted files open in editor buffers you might be able to write them back
>> out but any pending renames will be messed up badly.
> I'm not clear about revert vs renames; can you give an example?

I think what he meant is the following:

$ mtn mv a b
$ edit b
$ mtn revert b
$ edit / save b again

You end up with an unknown file b because of course your editor doesn't
get the info that the rename was reverted.

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