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 [EMAIL PROTECTED] 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.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-hackers
