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

[Peter Bex]

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.

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

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.

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.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

pgpJErLZs18j7.pgp
Description: PGP signature