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

[William Uther]

On 26/02/2007, at 9:51 PM, Markus Schiltknecht wrote:

> > 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.
>
> Uhm... I recall talking about that on the summit. I didn't exactly  
> follow the complete recent thread...
>
> Did you consider all corner cases? Does monotone now act  
> consistently for all commands? I.e.:
>
> mtn drop ${STH}:
>  - file ${STH} exists

File exists and is under version control and is unchanged:
  deleted with message about dropping from manifest (as currently -  
maybe should change?)

File exists and is under version control and is changed:
  dropped but not deleted - warning given

File exists and is not under version control:
  not deleted - warning given

File doesn't exist and but is under version control:
  dropped from manifest with message

File doesn't exist and is not under version control:
  Warning given

>  - dir ${STH} exists and is empty

exists and is empty and under version control.
  deleted with message about dropping from manifest (as currently -  
maybe should change?)

exists and is empty and NOT under version control
  not deleted - warning given

>  - dir ${STH} exists and is not empty

dir exists and has a child that is under version control (and -R not  
given)
  Not removed or dropped and a warning given.

dir exists and has a child that is not under version control (and -R  
not given)
  dir is dropped but not removed and a warning given.

dir exists, and is not empty, but is tracked and only has tracked,  
unchanged, files in it and --recursive is given
  deleted and message about each object being dropped from manifest

dir exists, and has tracked, changed files in it and --recursive is  
given
  changed file is dropped but not deleted with warning
  dir is dropped but not deleted with warning

dir exists, but has untracked children and -R is given
  dir dropped but not deleted and warning given

>  - dir ${STH} does not exist

same as missing file above (how do you tell between a missing file  
and a missing dir?)

> mtn add (--bookkeep-only)?  ${STH}:
>  - file ${STH} exists
>  - dir ${STH} exists
>  - no 'something' exists - here, monotone currently bails out  
> correctly. But do we want to support 'add --bookkeep-only'? How do  
> we know if ${STH}  is going to be a directory or a file? (Probably  
> we don't want to support that?)

I didn't think that made any sense, so I didn't add that option there.

> mtn rename S{SOURCE} ${TARGET}:
>  - uff... any combination of ${SOURCE} exists or not and ${TARGET}  
> exists or not.

I didn't really touch the rename code.  It seemed to handle all these  
cases already.  I did turn one silent log message into a non-silent  
warning.  The thing about rename is that it never actually removes  
anything so your data is safe... hence my less stringent testing.

> Do we want to call that argument '--bookkeep-only'? That seems ugly  
> to me. And I don't recall naming what monotone does 'bookkeeping',  
> anywhere else.

I'm more than happy to have a better name.  I didn't want "--no- 
execute" because, as Nathaniel pointed out, that is confusing.  While  
clunky, I think this name is clear.

> >   I tried sending the patch to the list, but it was too large (the  
> > meat of the patch is fairly small, but there were a lot of tests  
> > to fix up).  I've put it on the web (with my other monotone  
> > patches) here:
>
> Why don't you simply get a monotone key? Send the public key to  
> Nathaniel, he will happily give you push access to venge.net...

er, okie.

Be well,

Will           :-}