Re: [Gnu-arch-users] Status of global and tree aliases

[Tom Lord]

    > From: Andrew Suffield <address@hidden>

    > On Tue, Jul 20, 2004 at 12:27:07PM -0700, Tom Lord wrote:
    > > (As a minor point, the names "tree" and "global" are confusing.  By
    > > "global" I think you really mean "user" and by "tree" I think you
    > > really mean "version".  One thing missing in your proposal is (what I
    > > would call) "tree" aliases -- those specific to a particular project
    > > tree (but just that tree -- not committed along with the tree).

    > No, these really are tree aliases. 

Did I misread?  Jblack gave them a "source" filename.  They would be
archived.  In effect, they are persistently set (though mutable)
per-version.

In fact, here's what he says:

    jblack> Tree aliases are stored in
    jblack> workingcopy/{arch}/=meta-info/=aliases/[aliasname] (again,
    jblack> without brackets). Tree aliases are saved when you commit
    jblack> the file.

Back to you:

    > Version aliases are something else that may also be desireable,
    > but I'm damned if I can see how to implement them sanely
    > (problem: which version do I look in?).

I don't see why it wouldn't be the default version of the tree.

I'd be much more worried, if I were you, about how aliases (and other
version variables) interact with _merging_, although (you'll see
eventually) that that problem has a convenient solution in `xl'.

That's one of the significant problems I see with jblack's approach:
it will interact oddly with merging, probably often not in the
intended ways.

    > The significant distinction here is that if I get a tree, then replay
    > a changeset over it, that replay may change the value of a tree alias,
    > but may not change the value of a version alias.

Actually, it would be undesirable if a merge could _not_ change a
version variable.   It's only important that verges can change version
variables in controlled and domain-specific ways.

For example, suppose I am your upstream.  Your version has an alias
`upstream' defined that points to me.   If I cycle my archive, I
should be able to commit a change that, when merged, will update your
`upstream' (though perhaps with protection -- such as asking you to
confirm the change before it is committed).


    > (You've also described precious tree aliases - I'm not really sure if
    > those are useful, but they are different again)

I do plan to support per-tree overrides of version variables, both
transient (not committed) and permanent (will be committed).


-t