[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Status of global and tree aliases
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Status of global and tree aliases |
Date: |
Tue, 20 Jul 2004 14:07:36 -0700 (PDT) |
> 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
- [Gnu-arch-users] Status of global and tree aliases, James Blackwell, 2004/07/20
- Re: [Gnu-arch-users] Status of global and tree aliases, Tom Lord, 2004/07/20
- Re: [Gnu-arch-users] Status of global and tree aliases, Andrew Suffield, 2004/07/20
- Re: [Gnu-arch-users] Status of global and tree aliases, Aaron Bentley, 2004/07/20
- Re: [Gnu-arch-users] Status of global and tree aliases, Tom Lord, 2004/07/20
- Re: [Gnu-arch-users] Status of global and tree aliases, Aaron Bentley, 2004/07/21
- Re: [Gnu-arch-users] Status of global and tree aliases, Tom Lord, 2004/07/21
- Re: [Gnu-arch-users] Status of global and tree aliases, Jan Hudec, 2004/07/21
- Re: [Gnu-arch-users] Status of global and tree aliases, Tom Lord, 2004/07/21
Re: [Gnu-arch-users] Status of global and tree aliases, James Blackwell, 2004/07/20