[Top][All Lists]

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

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

From: Robert Collins
Subject: Re: [Gnu-arch-users] recent changes in address@hidden, and star-merge and update/replay defaults
Date: Sun, 09 Nov 2003 11:44:51 +1100

On Mon, 2003-11-10 at 11:13, Colin Walters wrote:

> It depends on what you think of as "the same line of development".  If
> the user intends to just track the latest development version, it IS the
> same line.
> > To me, this is a config management issue, [...]
> Configs can solve the problem, yes.  I think however that having
> replay/update normally track updates is easier, and that configs are too
> heavyweight; see my other message.

Be that as it may. changing branches by surprise on the user is -not-
appropriate for the general case. Consider that the user will still be
committing into their own '0.6' version, while getting your 0.7 version
changes. It violates the principal of least surprise. If the user wants
to be tracking your latest code of any version, then something external
that knows to accomodate things changing, new libraries being added in
and the like is an appropriate solution: which is what a config is. CVS
really suffers in this area.

As to the heavyweight claim: configs don't need to be in an archive. In
config-manager (my testbed for config generalisation) they don't even
need to be in a file. If you are talking about end users grabbing your
code and tracking over long periods of time, with minimal training...
script up a 3 line config driver script that will create and use a
config on the fly.

GPG key available at: <>.

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

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