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

[James Blackwell]

James Blackwell:
>
>     > Normally, I don't announce something before its actually working in a
>     > usable form, but considering some of the other posts going 'round on the
>     > mailing list, now is probably the time to talk.
>
> It's good that you did.

Well, I'm always willing to consider opinions. :)

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

Tom Lord:
> I'm sorry if I misled you when I mentioned the questions of "how to
> merge aliases" and "how to represent them".  They were meant to be
> leading questions not hints to pick the answer you appear to have gone
> for.

I think it's a viable addition, though I'm not sure how much use it'll
really get (other than specifying upstream)

Tom Lord:
> Aliases, I think, are a special of version variables and the
> implementation should reflect that.  It's perhaps also worth pointing
> out that aliases may very well usefully be more than just a "nickname
> -> version" mapping (e.g., an alias might has an associated pqm
> address).

I'm not addressing version variables at all. I think thats a different
issue. Sorry if I confused you by using "upstream" as an example.

Tom Lord:
> (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).

I not partial to any particular name. Originally, they were global and
archive aliases. Aaron Bentley talked to me about it, and convinced me
that there was enough of a consensus to change "archive" to "tree". I
don't mind doing the same for "user" aliases.

James Blackwell:
>     > Can I do stupid things with aliases?
>     > ------------------------------------
>     > Of course you can! If you alias "address@hidden/tla--devo--1.3"
>     > as "address@hidden/tla--devo--1.3", then when you type tla get
>     > address@hidden/tla--devo--1.3, you'll get Lord's version
>     > instead. 
>

Tom Lord:
> That is completely unacceptable and easily fixed.  The introduction of
> aliases should not create syntactactic ambiguities like that.

Actually, its a moot point by now, because an earlier conversation
convinced me that this syntax is better: 

$ tla alias --user --add lt address@hidden/tla--devo--1.3
$ tla get /lt/

This allows us to perform subexpression aliases, and removes all
possibility of ambiguity.

James Blackwell:
>     > Somebody else thought aliases up first!
>     > ---------------------------------------
>     > Yeah. Over the past couple years, a few people have thought about the
>     > problem too, and they came up with very similiar ideas. I guess its time
>     > that somebody actually did the work. :)
>

Tom Lord:
> The work started several weeks ago, actually.

Not that I'm aware of. The closest thing to aliases I've seen 
is furth, and the consensus on furth is that it should not be included
in arch. That leaves three possible avenues that I can come up with:

  1. You're going to change a lot of minds in your re-explanation of
     furth

  2. furth will not be implemented in arch.

  2. You're intending to put furth into arch even if the rest of the
     arch developers say "no".


On the other hand, the aliasing, as I've outlaid it, does seem to be
building a consensus. People have brought up some good points on some
minor issues, but those have been ironed out for the most part. In fact,
of the seven or eight people that I've communicated with regarding
aliases, your reaction is the closest I've seen to a negative reaction.


James Blackwell:
>     > This idea sucks because of [some small reason]
>     > ----------------------------------------------
>     > Yeah yeah yeah. There's a couple small problems with the idea, but what
>     > solution doesn't have a tradeoff or two? This is reasonably simple to
>     > implement, and solves a dislike that a *lot* of people have with
>     > arch -- namely that there's too much typing involved just to run
>     > it.

Tom Lord:
> Unfortunately, the "small reasons" here are of the sort that
> accumulate over time.   Your proposing a very ad hoc way to set just
> one specific kind of per-version or per-user parameter.   But that's a
> very general problem and so it merits a single, general solution.

I was referring to how no solution is flawless. I don't think that we'll
bump into many small problems (or any significant ones) with aliasing
implemented this way. I've spent a week considering ways that people can
break this solution, and it looks pretty solid to me.


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400