Re: [Monotone-devel] [bug #29927] mtn clone removes existing bookkeeping directory on failure

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> mtn clone allows to be executed in ".". When this directory contains a
> monotone bookkeeping directory, the cloning is aborted, but the original _MTN
> directory is also removed!
>
> ...
>
> I can think of two ways to fix this bug:
>
> a) check for an existing bookkeeping directory separately before the cleanup
> helper is created
>
> b) don't allow setup / clone to be called for an existing directory

Does "exising directory" include "nested directory"? For example:

cd root
setup project1
cd project1
mkdir project2
cd project2
setup .

Is that final 'setup' forbidden by b)? or is only this forbidden:

cd root
setup project1
cd project1
setup .

This latter case should definitely be forbidden, and for clone and
checkout as well; it is certainly an error to replace an existing
workspace by another one.

The nested case is probably a user error (it always is for me), but
there's no intrinsic reason mtn can't support it.

> On a related note - clone uses the branch name as directory name for the
> clone if no directory has been given explicitely while setup defaults to the
> current directory (".") - do we want to unify these? I'd propose that both
> fall back to the branch name as directory name.

I think the use cases are significantly different. clone is remote
checkout; both populate a new workspace with an existing branch, and
both use the branch name as the default directory name.

setup has two use cases:

1) convert an existing directory directory tree into a mtn workspace,
   often on a new branch, unrelated to any existing branch

2) create a new empty workspace, presumably on a new branch

For use case 1), "." as the default makes sense. For use case 2, the
branch name makes sense. 

In practice, I never use setup :). setup is only needed for totally new
projects, and I just don't do that often enough to get used to it. So I
don't really know which use case is more common.

Since the command is rarely used, perhaps it should not have a default;
force the user to be explicit about what they want, since they won't be
used to whatever the default is.

-- 
-- Stephe