[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. :-)


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


reply via email to

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