Re: [Monotone-devel] [PATCH] Make --execute default

[Nathaniel Smith]

On Sun, Feb 25, 2007 at 06:44:44PM +1100, William Uther wrote:
>   I've just finished a patch to make --execute the default.   
> Actually, it entirely removes the --execute option, and adds a new  
> option --bookkeep-only which is approximately the inverse of -e.   
> This also adds some checks to the drop implementation so that if you  
> try to drop a changed file (or a dir that isn't empty when it gets to  
> it) then it noisily falls back to --bookkeep-only.  This patch also  
> changes rename so that it warns when you're moving something and the  
> source is missing but the destination exists - it used to just  
> silently fall back to --bookkeep-only in that case.

I just did some poking around on our competitors to see what UI they
use for this stuff...

hg 0.9.3:

If you attempt to 'hg remove' on a file that was just added, or that
has been modified since the last commit, then you get a message:
  not removing foo: file has been marked for add (use -f to force removal)
  not removing bar: file is modified (use -f to force removal)
And nothing happens.  If you pass -f, then it deletes the file from
both disk and the manifest.

There is also an '--after' flag, which is documented to "record [a]
remove that has already occurred".  However, if you do 'hg remove' on
a non-existent file, then it works just fine anyway, and if you try to
do 'hg remove --after' on an existing file, it errors out anyway:
  not removing foo: file is still present
(I suspect that --after is more useful for, say, 'hg rename'.)

(If you use 'hg remove' on a directory, it appears to do nothing
whatsoever -- just silently gives you the command prompt back and does
not modify the workspace at all.)

If you simply remomve a file and do not tell hg about it, then it gets
annoyed at you -- commit fails.  (hg status, oddly, will complain
about missing files that were already in the workspace, but does not
give any warning for files that were only just added.)

bzr 0.14:

'bzr remove' never deletes files.  It is happy to run on files that
were just added or that have been modified locally.  It also takes a
switch --new which restricts it to files that were newly added in the
workspace (similar in effect to our 'drop --missing', just for a
different set of files).

If you simply remove a file and do not tell bzr about it, then bzr
status treats it as if you had bzr remove'd it.  (If you had only just
added it, then your add mysteriously disappears; if it had already
existed in the repo, then it is listed as deleted.)  At commit time,
after prompting for a log message, it _does_ complain about the file
being missing, but then goes ahead and completes the commit anyway.

There does not appear to be any equivalent to 'hg rename --after' at
all -- if you do a manual rename, then bzr assumes that you have
deleted the source file, so obviously you can't be meaning to rename
it, now...  (Also, you get a weird error message with python unicode
string literal syntax in it, it complains about the non-existence of
u'foo'.)

darcs 1.0.9rc1:

'darcs remove' never deletes files.  This is because the documented
and recommended way to remove files in darcs is to simply delete the
file; 'darcs remove' is documented to be used exactly in the case
where you want to record a delete without actually performing it
locally.

There is no --after style switch to either remove or mv.  However,
unlike bzr, it can still cope with moves that it is only told about
after the fact -- if I rename a file manually, then 'darcs whatsnew'
lists the file as deleted, but if I then say 'darcs mv <old name> <new
name>', it is happy to accept that -- the deletion disappears from
'darcs whatsnew', and a rename replaces it.  (Also, it appears that
darcs is smart enough to know that rename foo -> bar + rename bar ->
baz can be collapsed to a rename foo -> baz, but it is not smart
enough to know that add foo + rename foo -> bar can be collapsed to
add bar?  Or that add foo + remove foo can be collapsed to nothing?
Just going from the whatsnew output here...)

---- Conclusions:

So it actually appears that the the only thing that everyone can
apparently agree on is that the command is called 'remove' -- perhaps
we should consider dropping the name 'drop'? :-)

--after isn't a bad name -- maybe we should do that?

The missing-is-automatically-a-drop thing seems to make some people
happy.  And it totally side-steps the issue of what 'mtn rm' should
do, because everyone stops using it.  I don't see how to sensibly
navoid the problem bzr has, though, where once we've decided that
someone's manual rename was actually a drop, we can't really recover.
(Obviously darcs has some trick, but the cases that are hard, and
that we have already solved, are the ones where there are long strings
of complex rearrangements in the working copy, I'm not entirely
confident that it has a fully-thought-out model for tracking such
things.  Esp. since I was running into obvious warts in this tracking
in 5 minutes :-).)

I'm not sure I have any particular preference on whether the thing to
do when there are local modification is to print a warning, or to fail
out, or what -- I was sort of hoping that looking at the other
projects would reveal some consistency here :-).

I guess the one thing that does worry me about skipping the deletion
of such files and continuing is that if people miss that particular
warning in the scroll, then they will not realize that they have some
random files sitting around that they thought they had deleted.  If we
error out at the beginning of the command and don't do anything at
all, then it's very clear what has happened, and the user has the
command right there in their history buffer to re-run with whatever
added options they want.

But it's not that big a deal either way.

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen