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

[Mark Murray]

"Bill Page" writes:
> > > 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. :-)

FWIW, the FreeBSD project has ahout 300 developers, of which
about 20-40 are really active, and this works really well.

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.

> > OK, given the ammount of stuff I needed to do, that was
> > just not feasible. I found out how to do it, and
> > axiom--BSD--1 is now near-identical to axiom--main--1.
> 
> Mark, I'm very glad to hear about someone using the more
> advanced features of arch (star-merge, I presume?).

Just plain "merge", IIRC. Things still take forever while tla
"phones home" on occaision, but I've discovered caching (but
not tried it yet), so this may improve.

>                                                      If you
> have a moment to spare, I think it would be great if you
> could write up a little "I did it this way" recipe for others
> to follow. I find most of the arch documentation too obscure
> and unapplied to be easily digested. For my taste arch has
> too many ways of doing things and a lot of them not obvious
> nor intuitively named. But once you see how someone has made
> it work in a real situation it seems much more clear.

I'll try :-). There are still things that Arch does in a really
roundabout way that I'm really battling with. Like:

1) How to quickly commit 1 file out of the tree.

2) How to find all the diffs in a nominated list of files or in
   a dir (and maybe its subdirs).

3) How to blow away all the edits to one file only, one dir
   only, one subtree only and one list of nominated files only.

4) How to quickly replicate the tree so a mechanical edit/commit
   can be done to pristine sources.

.... and I'll no doubt find more.

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