Re: ***SPAM*** Re: [Chicken-hackers] multiple issues in embedded PCRE

[Matthew Welland]

On Friday 23 November 2007 06:03:15 am Peter Bex wrote:
> On Fri, Nov 23, 2007 at 12:44:16PM +0100, felix winkelmann wrote:
> > On Nov 23, 2007 6:19 AM, John Cowan <address@hidden> wrote:
> > > Fair enough.  Since the tarballs don't come with eggs (there is only
> > > one egg repository), in effect you have the best hope of using
> > > eggs if you have the trunk code replaced.  To have what other
> > > projects mean by stable releases, we'd have to branch the
> > > egg repository with each release and make sure that chicken-setup
> > > from a tarball invokes the correct set of eggs.  That way you
> > > could load 2.731 and get the 2.731-usable eggs with it.
> >
> > I lord... Even though I feel that this is the only really working
> > solution, the amount of storage, bandwidth and the added complexity for
> > the tools makes my head spin...
>
> I don't think the tools need to be changed.  You just need to point
> chicken-setup at a specific version of the egg tarball repository and
> it defaults to the one that matches the version, I think.

This doesn't seem that hard from my (posibly naive) perspective. 

In every release an "svn cp .../eggs .../rel-a.b.c/eggs" is done. 
chicken-setup merely needs to a) know the version and b) get the eggs 
from .../rel-a.b.c/eggs

> > Is this a viable approach? What do others think? How could one keep
> > track of bugfixes merged from one branch to the other? Is svn flexible
> > enough for this? Any opinions?

Simply don't do it. Bound your scope. NO BACKPORTING OF FIXES. All bug fixes 
are applied to the head. All the branches are locked and check ins are NOT 
allowed. BTW how merging like this works in svn is one more reason to not 
love svn :-)

> Do we really need a branch?  Just tagging the egg repos should be enough
> once a version is released, no?  The egg repos wouldn't change, since the
> chicken version is pinned to a stable non-changing version too.

A branch and a tag in svn are effectively the same thing. 

> Afaik you can only merge properly in one direction in svn.  You can merge
> bugfixes from a branch you're working on to other branches and to trunk.
> I think if you always merge every change from the branch to all branches,
> you can control it pretty easily.  You know the revision numbers to merge
> because you can ask 'svn info' the version before you start fixing the
> bug and you get it after checked in your changes (message "commited
> revision X")
>
> Otherwise, you could keep a list of merges from branch revisions in the
> branch directory of other versions, but that quickly becomes a headache
> unless you have a clear protocol on how to go about merging.  You can't
> apply the same diff twice to a branch so this can easily cause problems.
> My colleague tells me the svn team is working towards a solution for this
> problem.

Preaching to the choir I'm sure but other SCM systems don't have this 
problem (if I understand the issue correctly). My experience is limitied to 
bitkeeper and monotone, I have evaluated darcs, mecurial, git and a couple 
others also but settled on monotone. Anyhow, in monotone for example I 
can "propagate" a changeset to a branch quite easily. If I propagate again 
no harm is done. However what you describe sounds dangerously close to 
cherry picking and down that road lies insanity. I recommend not going 
there. I have used svn extensively for several years and once I ramped up 
on monotone I find using svn very limiting. Don't even think about cherry 
picking in svn. Well, ok. go ahead and cherry pick just don't attempt to 
use svn itself for the cherry picking. Create patches using svn diff. The 
manually apply those patches. 

Even after writing the previous paragraph I still say *NO BACKPORTING 
FIXES*!!!! The goal is NOT to make stable releases that can be picked up at 
any time and used. The goal (IMHO) is to make it easy for end users to 
stick with something that is already working for them. The end users can 
then move to a new release knowing that it is fairly easy to get back to 
where they were for either debugging wierd issues or proving that something 
*used* to work.

I really want to be able to seamlessly install a historical version of 
chicken and an associated suite of eggs all at the "right" version.

> Cheers,
> Peter

Matt
-- 
http://www.kiatoa.com, fight for a better world.