[Monotone-devel] Re: CLI / path restrictions.

[Bruno Hertz]

Nathaniel Smith <address@hidden> writes:

> On Fri, May 06, 2005 at 07:37:36PM +0200, Bruno Hertz wrote:
>> while the user interface might currently not be top priority, are
>> there still any plans to allow for non-recursive path restrictions,
>> e.g. for list various ?
>
> Hardest part is coming up with a sensible way for the user to express
> this desire -- any suggestions?

Hmm. Looking at common tools (like ls, chmod or whatever), restriction
to pwd is the default, and recursiveness must explicitly be requested,
like per '-R' option (OK, not possible with ls, of course). 'find' is
one of the notable exceptions, where recursiveness is the default, and
limitation to pwd or level of recursiveness is requested per
'maxdepth'.

I've seen the term 'depth' already being used somewhere, I think it
was the revision history depth of the log command, so there might be
some risk of confusing people.

But to meet user intuition somehow, I guess either of the above
approaches might serve as a model.

>
>> Also, remotely related and fyi, while diff takes a base name as an
>> argument, log requires a path relative to MT, which some people might
>> consider an inconsistency.
>
> Yeah, that's a stupid bug in log.  It never got updated to use Derek's
> no-longer-so-new "restrictions" stuff.  It'd be really nice if it
> could interpret the pathname correctly (using the same code that, umm,
> all the other commands that take pathnames use), and if it could take
> multiple filenames/directories, like all the other commands that
> restrict to part of the tree...

This especially since monotone does up-dir traversal anyway, to find
MT. I.e. the relative path to MT is always known, and having to
specify it always redundant.

> Though I guess the semantics of listing a directory are not totally
> clear; if I say 'log foo/', and there's a file foo/bar that used to be
> in some other dir, should the log include edits to foo/bar before it
> was in this dir?  if there used to be a file called foo/bar but is no
> longer, should the log include edits to foo/bar when it was in this
> dir?
>
> I guess my feeling is that log should do something like:
>   for each rev in history:
>     update list of explicitly mentioned files and directories
>       according to any renames that happened on the edge just
>       traversed
>     if this revision has any changes that touch any file that matches
>       anything in the updated list, output this revision
>
> The idea being that anything the user explicitly mentioned on the
> command line, we track its logical lifetime, over renames and all
> that.  And for those which are directories, we reinterpret this
> restriction again for each historical revision.  So the answers to the
> questions above are that we don't include edits to baz/bar even though
> it will later become foo/bar; and we do include edits to foo/bar even
> though it will later become baz/bar.

You take the discussion one step further than originally intended, as
the above 'dilemma' of course applies independent of how I have to
specify a path for log. It's rather a consequence of monotone
supporting renames by making trees the primary object of revisions,
which is a good thing, btw, and very neatly solved (although, as a
sidenote, from what I understand from the docs there's a one to one
relationship between revisions and manifests, making me wonder whether
there's a redundancy either ...).

Anyway, regarding your concern, I guess the log of a dir resp. the
content of a dir should contain the actions which happened on that
content at each particular revision step (I'm skipping merges for now,
since I'm actually no scm geek and have no clear picture on how to
proceed in those cases - an issue I've been thinking about these days
when wondering about how to present a diff history of a single file).

Anyway, as much as a file 'enters a directory' by adding, it basically
does the same by renaming. Regarding the directory, the file did not
exist there before, and that I think should be the general and imho
pretty intuitive semantics of log. Of course, log should report the
rename action as such, and in particular what the previous name was.

If this was agreed upon, the other direction would follow. I.e. if a
file was renamed some time ago and thus left the dir, the log would
include the file history up to that point, in analogy to a file
removal (you might add here that renaming actually is a re-mv-al on
*nix like systems).

This way, the complete history of a file is covered, admittedly at
then maybe different places but in a clean, logical and consistent
fashion users I believe will have no problem with. Even more, users
accustomed to thinking in categories of files, directories and paths
will presumably perceive any other approach as confusing.

>
>> Generally, I'm wondering whether it's possible to get rid off the
>> requirement the user entering MT relative paths at all, e.g. by taking
>> pwd into account.
>
> Yeah, that we haven't already is just a bug.  Do you know of any
> commands besides log that do this?

Not right now, but if you are interested in reports I might give them
as I go through the features resp. give summaries at specific
points. First though I hope to maybe ask some other questions in the
near future which have been kind of puzzling me these recent days ...

Thanks very much, Bruno.