Ralf Hemmecke <[EMAIL PROTECTED]> writes: | Hi Gaby, | | > | Now the "re-copying of the .svn directory"-problem is no problem anymore. | > This is great news! | | That is revision 75 now in branches/build-improvements
Thanks. | > | There were some problems with pamphlet files, in particular bookvol1 | > | and some others. | > Yes, bookvol1 has issues I could not solve last night (because of | > lack | > of time and I was tired). | | Me too, actually, I hope I did not make a mistake somewhere. I just fired up a build; I'll tell you :-) | But before other people could check out and test build-improvements, | you should merge with trunk. I have deliberately not put the unescaped | "&" problem that appears in src/input/zimmer.input.pamphlet since I | have seen that you have already committed a fix to trunk. | | > | I really wonder what silver/trunk actually is. It is not Gold, since | > | that "just works" and would not have latex problems. | | > To my mind, it is what we agreed on last april. | | But is silver/trunk now identical to Tim's "gold-to-be" branch? To my mind, there certainly will be things that need more testing before they become candidate for inclusion in the official release (Gold). So, I see Gold as almost a subset of silver, in the sense that it contains mature stuff and silver may contain more experimental facilities or improvements that are not ready yet for gold. silver is kind of "preview." For this to work out correctly, we need to know what patches are applied to Gold. That is, we don't require that Tim also maintain Silver. But, Tim should send patches he applies to Gold or whateter "fixed in the next release" refers to. In other word, we need some kind of "public record". | > yes, please put it there. Add brief descriptions of changes in the | > corresponding ChangeLog files. | | Done. But cannot we also use SVN to generate the ChangeLog file from | the SVN log? Or is this not common practice? Well, usually when I make modification, I describe that modification right away in the ChangeLog before thinking of commit. That way I don't forget about things, hours or days later, when it comes to commit. That is why it is not common practice -- from my exprience. But if you find it easier for you; that is OK too. As long as we have a "history" file that is not SVN oriented. | Hope things work out fine now. The build process needs a lot of clean | up. It is very hard for a human to understand the relation of the | makefiles. Yup. I'll commit in a moment an initial setup where I have just "translated" the existing configure. Then I'll move more work there. Ideally, I would like to see this finished before end of month -- before I point students to working on/with Axiom. -- Gaby _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer