[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Re: axiom--main--1--patch-31
From: |
root |
Subject: |
Re: [Axiom-developer] Re: axiom--main--1--patch-31 |
Date: |
Sat, 19 Mar 2005 14:01:15 -0500 |
> > > > and then do individual file diffs with hand merges.
> > > > Source code is too important to let the tools change
> > > > it.
> >
> > This is one point that I cannot agree with Tim about.
> > I think in order for Axiom to advance it must begin to
> > depend on the use of more sophisticated and higher level
> > source code tools - after all we now longer write much
> > in assembler language... It's time we begin to put more
> > trust in the tools (the right tools, that is). Oh ya,
> > I guess it was Tim who has suggested that all of Axiom
> > should actullay be written in lisp "machine language" ;)
>
> 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?
> An aspect of the way the Axiom project is run is still
> confusing me; there seems to be a combining of the concepts
> of "release" and "commit", so getting hold of daily development
> sources is Hard(tm). Is it not possible to make the more
> speculative edits available in "CURRENT" form, and apply
> a release-engineering methodology to preparing working
> sources for the consumption of the unwashed masses? I'm
> thinking of a CVS "HEAD" kind of approach, rather than
> the multiple-Arch-repos approach that is currently there.
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
There are various branches in the axiom archive, each subproject having
particular people associated with it (see arch.axiom-developer.org).
The HEAD branch is axiom--main--1. I don't do daily commits to this
branch. There would be no point. The changes I make are usually of
a large nature (e.g., add the browser, move GCLs, merge other branch
work, or periodic cleanups).
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 :-) ).
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.
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.
We should probably start an arch cookbook page on the axiom wiki.
t
RE: [Axiom-developer] axiom--main--1--patch-31, Bill Page, 2005/03/18
RE: [Axiom-developer] axiom--main--1--patch-31, Andrey G. Grozin, 2005/03/19
RE: [Axiom-developer] axiom--main--1--patch-31, Martin Rubey, 2005/03/19
[Axiom-developer] Re: axiom--main--1--patch-31, Mark Murray, 2005/03/20