[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: Colin Walters
Subject: Re: [Gnu-arch-users] recent changes in address@hidden, and star-merge and update/replay defaults
Date: Mon, 10 Nov 2003 01:49:39 -0500

On Sun, 2003-11-09 at 00:08, Robert Collins wrote:

> Is that the 'normal case' ?

Yes; for Rhythmbox there are a whole lot of people just using arch to
follow its development, and many fewer actually using arch for hacking
on it.  That seems to be a general rule for large free software projects
with fairly slow release schedules like GNOME.

> > 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.
> Not true: replay --skip-present is a good merge tool. As is non exact
> replay into a private branch (that is one where the local changes are
> not being propogated upstream). 

Fine, so you'd pass --exact to replay.

> [description of 3 line config making script]
> > Why should everyone have to write these scripts or whatever when there
> > is clearly a common pattern here that we can abstract and use?
> As Tom says, the common pattern is not yet clear. Saying 'why should
> everyone have to X' is a strawman here - I never suggested everyone
> should. 

But you did imply that was a solution to the problem, so the implication
that everyone who wanted this problem solved should do it certainly
seemed clear to me.

>  And if you write it, perhaps it can be generalised and thrown
> up on the wiki etc. Lastly, even if every project does one themselves,
> your argument about many end users vs developers suggests the overhead
> would be pretty low anyway.

It's not just writing it; it's the fact that it's confusing and
generally unnecessary.  

I don't see why tla shouldn't be able to function similarly to CVS for
such core things as this, but still scale up to development styles more
powerful than CVS when it's needed.

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

reply via email to

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