chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Re: repository branching


From: Felix Winkelmann
Subject: Re: [Chicken-hackers] Re: repository branching
Date: Sun, 24 Feb 2008 09:38:03 +0100 (CET)

From: Alex Shinn <address@hidden>
Subject: Re: [Chicken-hackers] Re: repository branching
Date: Sun, 24 Feb 2008 16:21:56 +0900

> >>>>> "Felix" == felix winkelmann <address@hidden> writes:
> 
>     Felix> It is not quite clear to me what you want to
>     Felix> achieve there, but in general, you'd do
>     Felix> *nothing*, let us branch the repository (you will
>     Felix> be informed when that happens)
> 
> Right, that's basically what I was waiting for :)
> 
> And also for warnings like the mail you just sent about
> uncommitted changes getting clobbered (I have those).
> 
> Think of me as an upstream maintainer, for the most part
> maintaining my code in external repositories, who takes the
> time to copy files over to svn and commit them mostly
> because it was such a low barrier to entry.  Even a
> relatively simple change in infrastructure is enough for me
> to want to hold off and worry about it later.  I don't like
> svn, I think branching just represents the fundamental
> brokeness of centralized version control systems, and would
> prefer to not spend my free time reading up on and learning
> about things I don't like.

Understandable. So don't worry about it. In fact, I think that
using the svn repo for development (committing work in progress)
often isn't ideal. Using a more lightweight, decentralized
tool (like darcs) for the daily work is preferable and faster.

I'm actually quite happy with svn so far. It turned out to be
extremely robust, considering the pounding the repository
has had to suffer in the years. 

> I'd also like to point out that although stability is a
> worthwhile goal, somewhat artificially freezing eggs
> according to what version they were in when the core Chicken
> version jumped from 2 to 3 doesn't help much in that
> respect.  Users who checked out eggs a year or two ago will
> still see any new changes to those eggs the next time they
> update or install on a new machine, and those changes may
> very well break things.  Users using Chicken version 3 will
> still see all new changes as eggs are modified.  Only users
> who from this point onward start to use version 2 will see
> any kind of stability.

Users should use chicken-setup to install eggs, not the svn
repo. You are right in that this perceived stability applies
to chicken 2 users only, but there will be more major
releases and a growing base of non-recent chicken installations
(hopefully) and for those we have to provide some sort
of stability.

The central problem is that we want a) keep older installations
working and b) allow quick turnaround for fixes for those
that use the current chicken. Still, I don't see a perfect
solution other than "freezing" the state for older versions
(but still allow maintenance).

> 
> The real solution is to have eggs depend on specific
> versions of other eggs, and to make all versions of
> everything available indefinitely, but that requires a lot
> of work and a lot of space.

Right. Would you like to help?


cheers,
felix




reply via email to

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