Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon

[Derek Scherger]

Thomas Moschny wrote:
> Derek Scherger wrote:
>> Pretty much all unix tools know what to do with "." as a path name. So
>> they could process the output from automate inventory or ls known/etc.
>> without first dealing with the root dir as a special case. A script can
>> open "." if it's running in the workspace root dir. It cannot open ""
>> without first changing it to ".".
> 
> What do you mean exactly by 'a script can open "."'?

Just that "." is a valid path while "" is not.

> If the current working dir is the workspace root, a script can access all 
> files within the workspace, whether they are named with a leading dotslash or 

Files yes but directories no I guess. For example mtn ls known doesn't
list the root dir and I think this is due somewhat at least to the lack
of a good name for the root dir.

> not, and if the current working dir is not the workspace root, the script 
> can't, again regardless of whether there is ./ at the beginning or not.
> 
> Additionally, accessing the current working dir using '.' is possible, but 
> seldom necessary, and rarely usefull. You can't use '.' (other than a target 
> dir) in commands like mv, cp, and so on. So, what are the use cases?

At the moment the following doesn't seem to work:

$ mtn attr set '' foo bar
mtn: misuse: empty path '' is invalid

Is there some reason I can't set an attribute on the root directory?

If I had changed an attribute on the root directory, mtn ls changed
would list a blank line because it didn't handle the special case and
output a more usable name.

I wonder what the lua attr hooks get with attrs on the root dir.

If I do the following:

$ mtn setup foobar --branch foo --db foo.db
$ cd foobar
$ echo foobar > foobar
$ mtn add foobar
$ mtn status
Current branch: foo
Changes against parent
  added
  added   foobar

Note the first added line. That's there because the root directory was
added as the parent of foobar.

There's just a bunch of little special cases like this and I once
wondered whether something like this would be better:

$ mtn status
Current branch: foo
Changes against parent
  added   .
  added   ./foobar

And from there I wondered whether the internal path format should
include those dots.

> It's not only the flag day, but also about invalidating all revision ids.

Hrm, for some reason I was expecting a flag day to do that but I guess
that's not necessarily the case.

> Maybe. You didn't cite or answer my last question, which was: Why prefix 
> *all* 
> paths in the db with a constant two-char string, when there never will be a 
> case where they are omitted for a reason?

I don't understand your question, or the previous one. Perhaps one too
many double negatives? Are you considering prefixing only *some* paths
(i.e. just the root path)?

If there never is a case where these prefixes are omitted for some
reason or another why *not* prefix them?

> Later someone will come and tell us how we can save two chars per path, or 
> some hundred chars per roster... ;)

Yeah, that's pretty much certain ;)

Cheers,
Derek