[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] patches

From: Ralf Hemmecke
Subject: Re: [Axiom-developer] patches
Date: Tue, 28 Mar 2006 15:29:15 +0200
User-agent: Thunderbird 1.5 (X11/20051201)

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

reply via email to

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