On Fri, Mar 02, 2007 at 09:58:51AM +1100, William Uther wrote:
When clone is not supplied a --db argument it creates a new db in
_MTN/mtn.db in the new workspace. If the clone command fails for
some reason (e.g. we try to clone a revision that doesn't exist in
the branch we specified) the we usually will not know this until the
new workspace has been created, the new db created in it, the branch
pulled from the remote server, and the rest of the checkout started.
[...]
Possible solutions:
i) Don't clean up (let the user clean up). This is at least saves
the database they've just pulled, although it is in a place they're
unlikely to find it by themselves.
ii) Don't clean up on windows.
iii) Someone fixes the problem on Windows. Unfortunately, I'm not
sure I can do this. I don't have access to a windows build
environment, and debugging by build-bot is, well, inefficient.
iv) Don't put the db file into _MTN? It's kind of a funny place for
it, seems to be causing trouble, and I worry it's going to totally
bite someone on the butt when they (spread out over some months) do:
$ mtn clone venge.net 'net.venge.monotone*' -b net.venge.monotone
src
$ cd src
src$ mtn co -r h:net.venge.monotone.foo ../foo
src$ cd ..
$ rm -rf src # don't need this checkout anymore
$ cd foo
foo$ mtn diff # errors out, missing database