Re: [Gnu-arch-users] Re: [BUG] feature plan -- downstream branches

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:

    > > It shouldn't be necessary to consult archives (e.g., read log files) 
    > > just to prune out downstream branches from an archive listing.

    > But, in my view, it shouldn't be necessary to name a branch in a certain 
    > way in order to hide it, and it should be possible to hide and unhide 
    > branches.  I'd like [ar]browse to consult the log file for the latest 
    > revision anyway, since it may contain such interesting stuff as 
    > "branch-status: inactive" or "branch-description: input validation 
    > fixes" or "successor-version: address@hidden/tla--devo--1.4"

Your view is something entirely different.

Your view only makes sense if I have ready access to all the archives
involved.  That's fine -- when I do, perhaps something like a
version variable that controls visibility is fine.   But sometimes I
don't have ready access to all the archives --- the a list of branch,
version, or revision names.   Those are already structured a bit --- I
can sort them sanely, for example.   With the addition of downstream
branch names, they'll be structured a bit more.

You could think of the arch package namespace as a kind of
impressionist painting of the kinds of structures you can create out
of the physical relationships of things like revision ancestry.

And that's exactllyl what the package namespace is for:  so that
people can paint a description of what they're doing, without being
compelled to render each and every detail 100% literally.

    > I'd rather see a separate file for per-version metadata, but if it's 
    > going in the patchlogs, I think browse commands should read the latest 
    > patchlog to see what's in there.

Browse commands can do whatever they do but the bottom line is I
should be able to give you a list of revision names and you should be
able to do interesting things with that list even if you don't know
where the archives live.


    > You said, "The latest patch-log entry for the tree-version of the 
    > project tree may contain a header"..."Variables without an explicitly 
    > set value have the value false".  So I'm assuming that when the patchlog 
    > gets cooked, it gets copies of all unchanged variables from the previous 
    > revision.  Is that a misinterpretation?

No, that's correct.   The anticipation here is that there won't be a
huge number of version variables and that the external representation
of their values won't be too huge.

If you need version-variable-like values that violate those
constraints by having huge values or by being large in number, then
don't use version variables at all --- use files in the tree being
controlled.


    > > The correlation between physical and logical up/down-stream
    > > relationships is, like ancestry and revision names, voluntary and
    > > deliberate.  That is, you have to explicitly choose to use a logically
    > > downstream name for a physically downstream branch, although the
    > > convenience commands encourage you to do so.

    > Sure, but it makes naming confusing, and I thought it would be a way to 
    > avoid the issue of "what character do we use".

Naming in situtations like this is inherently confusing.   A software
system that doesn't reflect that has oversimplified the problem.

-t