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

[Stephen Leake]

Derek Scherger <address@hidden> writes:

> mtn add is non-recursive by default but allows for --recursive if you want
> it.
> mtn revert is recursive by default and doesn't allow for an obvious way of
> being non-recursive (I believe --depth=N will stop the recursion at the
> specified depth).

A general --[no-]* option mechanism would help here (just building
motivation for this).

> So, which is more dangerous (1) accidentally adding some files you didn't
> mean to add, or (2) accidentally reverting a bunch of changes you didn't
> mean to revert?

> Recovering from (1) is easy, just revert the additions you don't want. Since
> revert is recursive this is no problem! ;)

Well, it is at least linear in the number of files/directories
accidently added; not necessarily trivial :).

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

It depends on what changes you are reverting. If you have edited a bunch
of files, and want to revert only one, but accidently revert them all,
that's a problem.

On the other hand, if you are reverting an accidental drop, recursion is
appropriate.

'undrop' makes this even easier; see the separate thread on that.

One solution would be for 'revert' to move clobbered files to
_MTN/resolutions if --move-conflicting-files is given, as update does.

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

I'm not clear about revert vs renames; can you give an example?

> $ mtn add a # non-recursive
> $ mtn add a/... # recusive
>
> $ mtn revert a # non-recursive
> $ mtn revert a/... # recursive
>
> I'm not sure how we'd represent a recursive revert of the entire workspace,
> maybe 'mtn revert ...' or something.
>
> Comments?

I think this is clearer than the current state. But making it backwards
compatible would be hard, I think.

-- 
-- Stephe