[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] [bug #29927] mtn clone removes existing bookkeeping
Re: [Monotone-devel] [bug #29927] mtn clone removes existing bookkeeping directory on failure
Fri, 21 May 2010 05:51:51 -0400
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt)
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:
Is that final 'setup' forbidden by b)? or is only this forbidden:
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.