[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [PATCH] per-archive IDs
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] [PATCH] per-archive IDs |
Date: |
Sun, 28 Dec 2003 11:18:34 -0800 (PST) |
> From: Charles Duffy <address@hidden>
> The core idea here is ~/.arch-params/=ids/<archivename> can
> store the user's ID for that given archive. This is useful, to
> steal a scenario from the test cases, one wants to commit to
> address@hidden as Jane Doe <address@hidden>, but wants to
> commit to address@hidden as Jane Doe
> <address@hidden>.
> "tla my-id" now takes a -A flag (to force the association for a
> specific archive), and a "-d" flag (to force the association to
> be made to the default ID, and not to an ID tied to a given
> archive). Running "tla my-id" within a project tree by default
> sets or retrieves the association of the archive that project
> tree belongs to.
I would like this change to be upwards compatible with the current
behavior of my-id. Would you please consider changing the interface
to:
usage: tla my-id [options] [id]
-h, --help Display a help message and exit.
-H Display a verbose help message and exit.
-V, --version Display a release identifier string
and exit.
-a, --all Print all of my ids.
--for ARCHIVE Set/print an id specific to ARCHIVE
-t, --tree Set/print an id specific to the
archive of this project tree
--delete Unset your id.
-u, --uid print only the UID portion of the ID
(The -e option can go away as far as I'm concerned)
In other words:
tla my-id print my default id
tla my-id ID set my default id
tla my-id --for ARCH
tla my-id --for ARCH ID
Print (set) my ID for ARCH
tla my-id -t
tla my-id --tree
tla my-id -t ID
tla my-id --tree ID
Print (set) my ID for the archive
of the current project tree
% tla my-id -a
default name0 <uid0>
ARCHIVE1 name1 <uid1>
ARCHIVE2 name2 <uid2>
...
% tla my-id -a -u
default uid0
ARCHIVE1 uid1
ARCHIVE2 uid2
...
% tla my-id -a ID
my-id: usage error (can not use -a when setting an id)
> So -- I'd appreciate a bit of peer review on this, not just the
> patch (which to my eyes is fairly trivial) but also wrt the
> desirability of the implemented behaviour.
I suspect it is desirable.
-t