[Top][All Lists]

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

[Gnu-arch-users] Re: recent changes in address@hidden, and star-merge an

From: Mike Hearn
Subject: [Gnu-arch-users] Re: recent changes in address@hidden, and star-merge and update/replay defaults
Date: Sun, 09 Nov 2003 13:26:23 +0000
User-agent: Pan/0.14.0 (I'm Being Nibbled to Death by Cats!)

On Sat, 08 Nov 2003 19:09:38 -0800, Sir Tom Lord scribed thus:
> The existence of that pattern and its importance/commonality is not
> clear.

For what it's worth, I'm a simple end user of arch currently, and so far
I've agreed with all of Colins proposals. In fact on IRC I suggested that
replay/update should be able to cross version boundaries.

Robert talked about the principle of least surprise. It surprised me when
I found that if I released a new version, suddenly for users tracking my
code replay would just "stop working" and they'd have to know we'd
released a new version, manually set the tree version and then continue.
This surprised me, and it surprised the people who were tracking my tree. 

Basically, I think it'd be good if when users issued a command like "tla
get address@hidden/fsdg", it did in fact expand to
fsdg--mainline--<latest-version-here> and then tracked the latest version.
If they specified a particular branch and version in tla get, then
replay/update would not cross versions.

I can say that I track several projects via CVS already, and just being
able to do "cvs update" every so often is very convenient. No thought
required. I don't feel like CVS is outsmarting me, or taking away
flexibility in this instance, I feel it's working with me to save me

So, as a user, I'd vote +1 to this, and +1 to allowing categories to have
default branches (possibly able to be changed, but definately with
mainline being the standard default name).

thanks -mike

reply via email to

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