[Axiom-developer] Re: cvs

[root]

> Ok, sorry. I did forget the update step. If I had done the
> update would everything have authomatically been alright or
> would I have had to manually delete my copy of the files
> which you had separately deleted in order to avoid having
> them re-added?

It comes with practice which is why I first set up a local CVS
then the CVS on tenkan before I started using the main website.
On the first CVS I used remotely I uploaded my whole home directory
including my mail files. 

If I delete a file and you do the update then the cvs command will
delete your copy of the file when you do the update. In order to
avoid stepping on other peoples changes everyone must do a cvs update
before doing a commit. The cvs update will try to merge changes that
don't conflict but will complain about ones it can't. You need to
merge changes that cvs cannot before you check in the files.

> Understood. I am amazed once again that the open software
> movement has gotten as far as it has with CVS. But that's
> dedication, I guess. But once one learns to cope with the
> limitations of some complex tool, it is hard to give it up
> even when something better and easier to use comes along...

The linux kernel people have partially migrated to bitkeeper.
Bitkeeper is a much better idea and they let free software
projects use it for free. However it is the subject of endless
religious wars and we don't need the grief. There is also a
free version call subversions, I believe. Change control is
always a painful subject and I've never seen a system I liked.

Hosting Axiom on savannah makes CVS the required default so 
using other tools is a moot point.

If the number of developers gets large enough we'll have to
appoint a person as the "librarian" to centralize changes.
That person would be responible for applying and testing changes.

In the kernel there are many cvs trees although Linus's tree
is "the master" people like Alan Cox maintain their own tree.
You can check out the -ac version to get Alan's copy. Alan
maintains patches that either Linux won't accept, Alan thinks
aren't quite ready, or are specific to things Alan wants.

> You are absolutely right that I should have tested the
> change to the database first (by re-compiling interpsys
> again after changing the database files, obviously)
> *before* uploading my changes to the CVS. Sorry.

I follow this cycle:

1) I have a local tree where I make changes. There are currently 3 
   local trees with changes "in process" in parallel.
2) Once I'm happy with a local tree I do a cvs checkout of Axiom
   to a clean directory (call it directory A) and apply the changes 
   to that directory copy.
3) I do a build in the A directory.
4) I do a clean checkout of axiom into a B directory and diff -R A B
5) I copy the changed files to my "master" directory
   and do the cvs adds/deletes
6) I copy the master directory to a local directory C and do a build
   along with testing.
7) I cvs checkin the master
8) I cvs checkout the master to local directory D
9) I make directory D

It is a painfully long dance but I inserted the various steps 
because I make a lot of mistakes and each step catches some of
the errors. I still manage to shank one occasionally.
   

> The current interp/Makefile does not actually update
> the database files. How do you plan to handle this in
> the future? Would this normally be done as part of
> every build? So does this always mean that we have to
> build interpsys twice?

Yes, interpsys will eventually be built twice as part of the build.
During the second build there are a large number of function-calling
optimizations that get applied which considerably speed up the
execution.

The database files will only get rebuilt if they need to be.
Currently databases are rebuilt every time. This used to be
implemented in Scratchpad but seems to have disappeared.

Tim