Re: [Monotone-devel] Re: listing unknown directories

[Nathaniel Smith]

On Wed, Nov 29, 2006 at 07:24:26PM -0800, Zack Weinberg wrote:
> On 11/29/06, Nathaniel Smith <address@hidden> wrote:
> >On Thu, Nov 30, 2006 at 03:10:02AM +0100, Thomas Moschny wrote:
> >> I know that this is really different from current behavior, but it seems 
> >to be
> >> much more natural. And more similar to what other commands do, e.g. svn.
> >
> >This superficial difference from svn exactly reflects a deep
> >difference from svn -- svn has no "whole tree" level, it always works
> >on arbitrary subdirectories.  mtn is very very committed to having a
> >"this is the whole tree, there is no other level" view of the world.
> >
> >> > Maybe the real problem is calling those commands "ls", which creates
> >> > an expectation that they will work like, well, ls(1).
> >>
> >> So you are saying that instead of meeting the user's expectation, we 
> >should
> >> rename those commands?
> >
> >Yes.  This will give the user different expectations, ones that they
> >may like just as well, and that are easier for us to meet.
> 
> I see what you're saying, Nathaniel, but I have to come down on
> Thomas's side here, because this *isn't* a mtn vs. svn issue.  It's a
> mtn versus *every other Unix command* issue.   If we make mtn commands
> in general operate on their subdirectory and print paths relative to
> the original cwd, that's going to make using it from shell scripts
> much easier, no matter how we decide to spell "ls unknown".  Read back
> upthread about how people were complaining about not being able to do
> "mtn ls ignored  | xargs rm" from a subdirectory.

Another possibility to throw into the mix: a --relative switch that
works equally on every command, and makes them all print paths
relative to the pwd.  The advantage would be that it supports the
piping use case without either forcing all commands to give relative
paths (which is dubious for non-ls commands, see also below), or
introducing inconsistency between mtn commands.

> [ To preserve the mtn model I could support causing "mtn commit" to
> error out if invoked from a subdirectory, although I think there are
> project tree layouts for which that could be incredibly annoying. ]

I see your point, but I am _really_ dubious about the idea that
'diff', 'status', and 'commit' should by default be restricted to the
current directory.  Like, just speaking as a user, I suspect that
would personally frustrate me :-).  Note also the desiderata that
these commands should have identical processing of restrictions etc.,
so that you can diff and status and then commit.

Also, to just remind everyone who hasn't been lurking for the last n
years, the other traditional argument for mtn commands being
unrestricted by default is that in this model both common use cases
are very natural:
   current dir: mtn commit .
  unrestricted: mtn commit
but in the other model, one is not natural at all:
   current dir: mtn commit
  unrestricted: mtn commit ../../.. # or was that ../../../..? ../..?

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco