Re: [GNU-arch-dev] Re: [Gnu-arch-users] new documentation progress

[Robert Collins]

On Fri, 2005-04-08 at 15:22 -0700, Tom Lord wrote:
>    >> Always giving root the same tag means that many important control
>    >> files always have the same tag (using only generic rules for how those
>    >> tags are constructed).
> 
>   > Uhm. All current files in Arch are either names tagged
>   > - ?[_]./path/to/file-or-dir
>   > or explictly id'd via external id files or in-file taglines.
> 
>   > Unless I'm badly mistaken giving the root a different id has no effect
>   > on the ids of any other files. 
> 
> Think more algebraicly:
> 
> The root and its id are a kind of `0'.
> 
> Given a directory id and a relative path from that directory
> to a particular kind of control file, one can reliably construct
> the id of that control file.

Ack - for project trees that store this data as files.

> So, sure --- arch could assign a patch log file the same id it
> currently does even if the root id could change.  On the other
> hand, the id of a patch log file can be computed using generic
> algebra rules, given only its path relative to `0', the root directory.

... and ? You can compute it using these generic algreba rules -
but /none/ of the libarch code *does that*. All the inventory
implementations I've seen use names rules for the id calculation of
patch logs.

> People sometimes argue that it would be useful if one could "rename"
> a subdir to be the root and the root to be a subdir.  It is noteworthy,
> though, that any such rename operations, to be valid in arch, would
> *have to be* accompanied by a rename of the `{arch}' directory.  In other
> words, no matter what, the root directory is a special case.

For the current project tree format sure. But I can imagine a sane
project tree format where the control dir is the special case, with no
parent id needed. Equally(and more importantly), renaming the root isn't
the most important use case. the most important use case is joining
disparate trees with the remote tree becoming a subdir of this tree, and
successive updates from that tree adding new files to its root to this's
subdir.

> Given that the root dir is always a special case, giving it a fixed
> id (and thus avoiding to *ever* have to rename `{arch}'), is
> actually something of a simplification.

I don't recall saying it wasn't a simplificiation - but I think its a
design bug that imposes some serious functionality limits.

I'll put up some thoughts on wiki shortly, under both the changeset
docos and the project tree doco which this impacts, but off the top of
my head we need:

* id aliases, so that when we join two trees with different roots, we
can inexact patch without spurious conflicts.
* {arch} control data special cased - a basic implementation of
supporting different changeset formats will give us this
* an extension to join-branch to allowing specifying the path to join
at.

Rob

signature.asc
Description: This is a digitally signed message part