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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: James Blackwell
Subject: [Gnu-arch-users] Status of global and tree aliases
Date: Tue, 20 Jul 2004 12:52:10 -0400
User-agent: Mutt/1.5.6+20040523i

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.

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

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.

Why do we have two types of aliases?
-----------------------------------

Well, what I really wanted was global aliases, for several reasons. Global
aliases work everywhere, in every tree. Though they're generally less
useful, there are also a couple places where we can use working tree
aliases effectively. Since global aliases and working tree aliases are
both very similiar problems, I decided to do both at the same time.

What happens if there's a conflict between global and tree aliases?
-------------------------------------------------------------------
Since tree aliases are potentially defined by a third party (the archive
owner), I've decided that if there is both a global alias and a tree alias
with the same name, that the global alias (which you've defined yourself)
should take precidence.

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. Fact is, people just aren't stupid enough to make this sort of
mistake unless its intentional (in which case its not a mistake)

So you're probably saying "Yeah, but what a security mess if some creep
does this with a tree alias in a working copy that I get". Don't worry
about that. You're already *in* a (her's?) working tree when you're using
working tree aliases. The only thing they could really do is muck up gets,
and merges from the working tree down. For example, aliasing version in a
working tree is actually a reasonably safe thing, because the supposed
damage is limited to just that working tree.

Seriously, if you think there might be a problem with working tree
aliases, spend a few hours thinking through the ramifications 
of whatever the problem may be. If, after thinking a couple hours about
it, you still think its a problem that can stop the show, then let's
discuss it. 

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

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.
I personally think that spending six months the problem, then spending
six months debating the solution, then spending six months coding,
then spending six months to convince the holdouts means two years of
putting up with the problem. This idea will work pretty well and is
reasonably simple to implement.

I love this idea, when will it be ready?
----------------------------------------
When I'm finished. :) I've spent about five hours on it so far, and seeing
as how I'm about 25% done, that means I've got another... 20 man hours on
it. Of course, that's just a reasonable guess. Typically I'll sit down and
work for four or five hours, take anywhere from the-rest-of-the-day
(likely)  to a week (less likely) off, and then do another 4 or 5 hours of
work... So, we're looking at a range from early next week until a month
from now (with a slightly more than zero chance of never finishing)

I hate this idea!
-----------------
Well, if you're alone in this thought, then it sucks to be you. Maybe
you'll get lucky and freak tornado will pick up a car and drop it on my
head. If a lot of people seem to dislike the idea, I can of course file it
away until the day that everybody starts seeing things my way. 



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




reply via email to

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