On 03/28/2006 01:15 PM, Page, Bill wrote:
On Tuesday, March 28, 2006 5:40 AM Ralf Hemmecke wrote:
Why don't you use tla?
Make a new branch from axiom--main--1, hack at the new branch
and if it is finished, tell Tim that there is something new
available ready for merge. Tim then could investigate that
branch, test and check documentation, and if he finds that
it is all fine just do a star-merge to axiom--main--1.
Would that be bad?
As far as I am concerned that would be Excellent! :)
Unfortunately skill and confidence in these tools is lacking.
I think it needs someone (or a small group of Axiom developers)
to take the lead, write **simple** documentation and demonstrate
exactly how this works.
Well, it took me some time to figure out a way how that could be done.
Bill, you know that I am currently in the process of translating
Broadbery's Java code to Aldor so that "Aldor for Axiom" could be built
without the need to install Java.
I also volunteer to write the documentation on the wiki related to this
tla stuff. Once one understands the basic things, it becomes easy. But I
wanted to commit to a local archive (without internet access) and then
merge with the one at axiom-developer.org. That was a bit trickier to
find out. But I think I have an acceptable way (simply create a local
personal archive).
I have not used 'tla star-merge', but I have used the similar
function of 'darcs pull'.
I have also quickly read through darcs. The idea that in darcs an
archive is just a collection of patches, sounds rather simple.
Star-merge in GNU arch is what it says. You branch from a certain
revision. Then two development lines appear on two different branches
(which have a common ancestor) where each of the branch maintainers can
merge from the other branch. Star-merge keeps track of which patches
have already been applied so that one patch is not applied several
times. That is all.
> It seems to me that these commands
save an enormous amount of time and protect against the common
errors of less automated methods of handling patches. The
decentralized model based on pulling (merging) patches from
separate archives also seems like a good idea. This allows the
work of maintaining an archive to be shared in a flexible
manner. Plus the 'darcs send' command can be used to create
and send patches by email with very little effort.
I also think that we should use the version control tools more
excessively, but unfortunately it takes a lot of time until one gets
accustomed to their different principles.
If you are accustomed to centralised development like in CVS, then it's
at first a bit hard to get the idea of how else development could be
done. Nobody writes, for example, that it is perfect, if you create your
one archive, JUST FOR YOURSELF, work on it and from time to time (if
things are reasonably stable), merge back to the version you branched from.
So there is one suggestion from my side. The version axiom--main--1
should be made read-only. That is declared to be THE stable branch and
only Tim (or any person that he trusts) has write access to it.
For anything else, people should branch from that one, create there own
private (or public on axiom-developer.org) archive, produce new code,
tell Tim, so that Tim could decide whether the changes should go into
axiom--main--1.
People (like me) feel more confident if they know that they don't
destroy the work of others if they start hacking on a new idea.
You hear/read more of that probably soon.
All the best
Ralf
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer