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

[John Cowan]

Matthew Welland scripsit:

> 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

Correct.  And to placate Felix, "svn cp" only takes small amounts of
extra disk space, just enough to cover the metadata.

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

I agree absolutely.  The only possible exception would be a security-related
bug, but I don't think we really have those except maybe in the web server.

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

Indeed.  It's just a matter of convention that a svn repository has
top-level directories called trunk, branches, and tags.  For my
project TagSoup, I store the released version under branches, but
they don't change, so they are semantically speaking tags.

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

All of those are change-oriented systems, where you can in principle
have 2^n versions from n changes (though of course most of those
combinations won't even build).  Version-oriented systems like rcs,
cvs, and svn (and remember that svn is only intended to replace cvs,
which it has done successfully) only have n versions from n changes.

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

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

And that's what distros want too.

-- 
John Cowan    http://ccil.org/~cowan    address@hidden
Economists were put on this planet to make astrologers look good.
        --Leo McGarry