gnu-arch-users
[Top][All Lists]
Advanced

[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 12:27:07 -0700 (PDT)

    > From: address@hidden (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.


    > I'm about 25% done with my aliases project for arch. The results of this
    > project is that you will be able to substancially reduce the amount of
    > typing that you'll have to perform for repetitive (why "repetitive"
    > instead of "repeatitive?") tasks. 

    > Here's how the interface to the aliases look: 
    > ---------------------------------------------
    > 
    > $ tla alias --add --global lordtla address@hidden/tla--devo--1.3
    > $ tla get lordtla
    > $ tla alias --delete --global lordtla
    > 
    > $ tla alias --add --tree upstream address@hidden/tla--devo--1.3
    > $ tla star-merge upstream
    > $ tla alias --delete --tree upstream

Those are plausible interfaces.


    > As for the nitty gritty details: 
    > --------------------------------

    > Global aliases are stored in ~/.arch-params/=aliases/[aliasname] (without
    > the brackets). The file [aliasname] contains the data that is to be
    > aliased.

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

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.

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).

(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).


    > 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. 

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


    > 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. :)

The work started several weeks ago, actually.


    > 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.

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.


-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]