Re: [Monotone-devel] Re: [long] subdirectory restrictions

[Derek Scherger]

> >   - Partial updates: These don't just create a fork; they create a 
> > completely
> >     independent new root node in your branch.
>
> yeah, these are actually very dangerous since they merge so well; I'm happy
> just leaving this disabled for a while.

Agreed. I almost wonder how important update is in general actually. It seems 
like it should be fine to never update and just merge the resulting heads later. 
Does it just provide more of a warm fuzzy CVS feeling than anything else? Update 
does represent some form of merge into working copy I suppose but a more general 
one might be better.

> >     There's also the standard pragmatic test, that asks which behavior is
> >     easier to emulate given the other... in my proposal, to get a full
> >     version diff, I say
> >       $ monotone diff
> >     and to get a diff of the current directory, I say
> >       $ monotone diff .

I like that too, typing ../../../.. is generally hard to get right if you're 
more than one or two levels deep. So the default is then the whole tree unless 
it's restricted by an explicit directory or set of paths. I would still expect 
that other paths should be considered relative to the current/starting directory 
rather than from the working copy root though, as they are now.

> you're right that --exclude can exist independently of --include, though;
> and I think I'm comfortable with this notion of returning positional args
> to their conventional role of meaning "included filenames". all well and
> good. on --exclude, then, anyone else have a preference?

Personally, I still think I prefer the idea of include/exclude (or 
addition/subtraction) operators *within* the list of paths if we could come up 
with acceptable names for them. In increasing order of complexity, this would 
allow for (1) an empty list of paths, meaning the whole tree, (2) a simple list 
of paths meaning to restrict to the specified set, (3) a simple list of paths 
followed by a relatively simple set of additional exclusions which is more or 
less equivalent to what njs is looking for and (4) a more complicated expression 
that would allow for something close to the shortest/optimal command line length 
in the general case.

Whether there's any significant value in (4) I'm not sure, but if people are 
concerned about working in tool poor environments or on systems with severe 
command line length restrictions then there might be.

There do seem to be concerns that (4) might supply a little too much rope and 
help people to get into trouble. Documentation would help and I would expect 
that in any non-trivial case people would try a safe command like monotone 
status on the expression to see that it produced what they were expecting before 
committing or reverting it. None of the other relevant commands do anything that 
would be particularly difficult to recover from so the risk seems pretty low.

The one thing I don't particularly like about (4) is that there is not (that I 
can think of) any prior art for doing this with command line arguments which 
certainly does raise a few red flags.

I'm not overly concerned with this either and I won't be too disappointed if 
everyone disagrees with me.
--
Cheers,
Derek