Re: [Gnu-arch-users] recent changes in address@hidden, and star-merge and update/replay defaults

[Colin Walters]

On Sat, 2003-11-08 at 19:44, Robert Collins wrote:

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

How will they be committing into their own 0.6?  We're talking about the
normal case of the user who doesn't have their own branch or anything;
they just want to use the revision control system to track the
development of a program.

If you were using your own branch, you'd generally be using star-merge;
if not, then you'd have to know to pass --exact to replay/update.

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

I can't see this as a normal case.  That is an advantage of configs,
though, I agree.

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

Why should everyone have to write these scripts or whatever when there
is clearly a common pattern here that we can abstract and use?

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