[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon
From: |
Derek Scherger |
Subject: |
Re: [Monotone-devel] partial pull #2 - gaps instead of a single horizon |
Date: |
Sun, 03 Jun 2007 23:48:06 -0600 |
User-agent: |
Thunderbird 2.0.0.0 (X11/20070520) |
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