Re: [Axiom-developer] Re: axiom--main--1--patch-31

[Mark Murray]

root writes:
> > I think I agree with this; one of the purposes of these SCM
> > tools is to help share the load, but it seems that aspect is
> > expressly forbidden for now. :-)
> 
> forbidden?

Erm, I reread what I wrote, and it is rather unfortunately written.

Sorry.

I meant that developers don't get a hand in on the daily editing,
rather it is a

submit-to-queue; queue-is-processed; receive-from-queue

model, which while working, is single threaded, and there is more than 
one developer submitting stuff.

So I guess a better way of saying what I meant is that I think you are 
going to get swamped when more folks start to submit stuff, and may 
want to consider a bigger team (No, I have enough work, thank you!).

> you're still thinking in CVS terms it seems. Arch has the notion
> of a changeset which is a single change that involves multiple files.
> For instance, the -30 to -31 change is mostly about moving to GCL-2.6.6

Sure.

> The flow of work seems to be:
> 
>   local changes 
>     commit to a branch
>       merge branch to main
>         monthly merge of main to savannah, sourceforge
> 
> whereas in CVS projects it was normal to do a CVS ci  and also
> to perform individual file changes. The two systems have completely
> different mindsets (and changesets :-) ).

Us CVS folks would _kill_ for CVS to grow changesets, but we still
would demand our daily bread^Wsource. :-)

We substitute by trying to commit related fixes together, but CVS
doesn't help us much here.

> The "latest" axiom sources that can be reached are usually in a
> branch. The main branch is at most a few weeks newer than the 
> golden sources on sourceforge and savannah. The local changes
> on my disk are always broken. Indeed, to do testing I usually 
> have do download and build the main branch because I rarely have
> a working copy available.

The FreeBSD model, in terms of the above workflow is

local change
   commit to HEAD
      merge Good(tm) changes to STABLE branch
         release STABLE branch every 3 months or so

And all developers have continuous access to the repository, and they
all know WHO may commit WHAT to WHERE. The developer who committed to 
HEAD usually does the merge to STABLE, and they usually have a jolly 
good idea about what is Good(tm), because rather a lot of people are
running CURRENT (==HEAD). World+Dog can check out 1/2-hour old checkins
and see if they solve reported problems.

And this is distributed. HEAD must not be broken, but as work is
shared,it sometimes is. This is OK, as long as we are not in a release 
cycle, and as long as reports of breakage are reacted to and sorted out 
quickly enough. Breaking STABLE is a capital offense. ;-)

> I chose to use arch because I follow the linux kernel work fairly
> closely. They have moved the kernel to bitkeeper which is a proprietary
> program. Arch was the closest I've found in the free world (SVN and
> Darcs were the other choices). I'm not overjoyed with it but then I've 
> never found a system that was obvious and clear. Arch is still an
> experiment and I may yet change my mind. 

SCM choice is rather limited, I agree. Perforce is VERY good at 
branching and branch merging, and its free to OSS folks. Its very full 
featured also. FreeBSD uses it for the more speculative/risky 
development projects, where is is not clear that the work is useful or 
can be finished.

> We should probably start an arch cookbook page on the axiom wiki.

That would help a LOT.

M
--
Mark Murray
iumop ap!sdn w,I idlaH