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

[Nathaniel Smith]

On Thu, Nov 30, 2006 at 03:10:02AM +0100, Thomas Moschny wrote:
> On Wednesday 29 November 2006 09:43, Nathaniel Smith wrote:
> > On Wed, Nov 29, 2006 at 09:19:23AM +0100, Thomas Moschny wrote:
> > > See
> > > http://article.gmane.org/gmane.comp.version-control.monotone.devel/7636
> > > and around. He was arguing about confused users and about consistency. Me
> > > personally, I was not convinced.
> > >
> > > Instead, I was confused when I had to learn that the paths monotone
> > > /accepts/ (from the cmdline) have to be relative to cwd, while the paths
> > > monotone /emits/ are always relative to the workspace root.
> >
> > So you argue that all paths monotone prints out, from all commands
> > including e.g. 'status', should always be relative to the cwd?
> 
> Indeed, and additionally all the affected commands (status, diff, ls, ... but 
> also commit) should be restricted to '.' (ie. the cwd) as long as the user 
> doesn't explicitly requests something else.

Man, this is just the week of tangential topics in monotone-devel
threads, isn't it :-).

> 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.

> > (what exactly do 'ls branches', 'ls certs', 'ls epochs', and 'ls
> > unknown' have to do with each other?).
> 
> That's a different issue, but I don't think that's a real one. At least the 
> linux people are used to lsmod, lsdiff, lsusb, lsattr, lsof, etc.

Hmm, I think I've used exactly one of those in the last 6 months, and
that like 3 times :-).  (lsmod, to figure out whether some kernel was
using a broken ("gen-rtc") or non-broken ("rtc") rtc driver...)  Not
that this is super relevant.

> > > Besides this, the zsh completion code could be less complex with relative
> > > paths.
> >
> > Unless you want to use things like like automate get_revision or
> > automate inventory, which certainly don't and won't use relative
> > paths...
> 
> That's ok. It won't start parsing revisions or inventories as long as one can 
> get simple file listings.

Oh, right, also -- not directly replying to your point, but, there
would certainly not be any problem with adding 'automate relativize'
and 'automate absolutify' commands.

-- Nathaniel

-- 
Electrons find their paths in subtle ways.