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

[Thomas Moschny]

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 "."'?

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

Besides, '.' is not understood by the tools (per convention), but a feature 
provided by the file system via a hard link.

> > Overall, the gain for such a big change (all manifests and revisions and
> > thus also their ids will change) seems to be rather small.
>
> Agreed. That's why such a change would be saved for some other flag-day
> inducing event. It certainly doesn't merit such a change on its own.

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

> It's also entirely possible that this is a silly idea and perhaps a
> better and simpler change would just be to *output* all paths with a
> "./" prefix and call the root dir "."

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?

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

Regards,
Thomas


-- 
Linux is obsolete
        -- Andrew Tanenbaum

pgpliHqQreE7i.pgp
Description: PGP signature