On Dec 17, 2007 9:19 PM, Sebastien Morin <sebastien.morin.1@xxxxxxxxx> wrote:
Hi Ed, The consistency tests code is now fully integrated into the 1.2 line...
I'll try to release a new relax version soonish with this new code. Hopefully I'll have time before this weekend, otherwise it will have to wait until after the new year as I'll be on holidays.
Thanks for the help concerning SVN !
That's no problem.
For the consistency tests code in the 1.3 line, I would like to start the work as soon as possible. Do I have commit access to this branch ?
You have full commit access to everything, including the webpages. So you can modify anything you like. Changes will need approval though. And I would prefer that most development occur in branches and then after I review and accept the code it can be merged into the main lines. The exception is the 1.3 line redesign which is going directly into that line. Because the changes are so massive, a development branch for this makes no sense.
Would it be a good idea to merge the changes that happened in the 1.3 line to the branch before starting the work (However, svnmerge does not seem to have been initialized in this branch right now.) ?
It is best to keep up to date. The internal changes since the branch have been immense and very radical! You will need to initialise svnmerge on the branch from the revision at which the branch was created. You can use svnmerge to keep your branch up to date. A word of warning though, with my current 1.3 line code changes, I regularly make relax fail before getting to the prompt. So I would run the test-suite on the 1.3 line prior to each use of svnmerge. I would also recommend creating a few unit tests for each user function and each function in the specific_fns and maths_fns code. Gary's unit test framework is a very powerful technique for weeding out bugs. This tests the proper behaviour of individual functions and their failure. From the 400 unit tests I have written so far, you should get a good idea there of what to do. I highly recommend adding tests here. I have been doing all of the new development by writing comprehensive unit tests prior to the actual code. Then I write the code for relax and debug until the tests pass, at which point the code is very clean. If I then realise I need to redesign something or make it more flexible, this net of unit tests then makes this code refactorisation very quick, especially for debugging. Cheers, Edward