Yes I can have a go. Time is quite tight here at the moment so if things are not going fast enough don't be afraid to yank it, back I wont be embarrased ;-)
Oh well, we'll see what happens.
To round things out
1. are you saying that I should be able to do one big bang merge at somepoint soon from the 1.3 branch? If so what is (or how do i find) the first revision I have to start from and how do i tell which revisions are relevant? (i.e. what is the latest revision to the 1.3 branch
You don't have to merge revisions one by one, it can be done in bulk blocks. I just did this type of updating with the 'tensor_pdb' branch. As Chris ported his r2719 into this branch (https://mail.gna.org/public/relax-commits/2006-11/msg00015.html), I have now bulk ported r2668 to r2717 and committed the lot as one revision (https://mail.gna.org/public/relax-commits/2006-11/msg00024.html). After that I ported the single r2724 to make the 'tensor_pdb' branch completely up to date with the 1.3 line (https://mail.gna.org/public/relax-commits/2006-11/msg00025.html).
For accounting for which revisions have been ported and what hasn't, you can use three different shells. In the first, if you are in the directory for the main 1.3 line that you have checked out, type:
$ svn up $ svn log -v --limit 50 | less
Depending on how active development has been, the limit may need to be increased. In the second which is in the main directory of your checked out copy of the 'test_suite' branch, type:
$ svn up $ svn log -v --stop-on-copy | less
This will give you the log of the branch for it's entire lifetime. The third shell, again in the 'test_suite' directory, you can apply the merge commands. In the subversion log of the 'test_suite' branch, if you type '/svn merge', all porting activity will be highlighted. You will then be able to see what has already been ported and can compare this to the log of the 1.3 line to see what needs to be ported.
For example, you should see that you have essentially ported r2717 (1.3 line) into the branch at r2723. Also there are currently only two revisions in the 1.3 line which haven't been ported to the branch. These could wait until whenever you decide that the changes of the 1.3 line are worth porting. It's best not to let too many revisions pile up in case the branch and main line get too out of sync. If changes occur to the same part of the code in both the main line and the branch, then 'conflicts' will need to be sorted out. If months pass, then merging may become a huge headache.
2. I guess avoiding multiple merges is just a case of noting the latest revision merged...
As long as the mergers occur sequentially and no revisions are accidentally left out, it should be fine. Multiple bulk merges should occur though.
3. I have corrected a bug in the float.py code within the test_suite branch while sorting out the unit tests. How do I back port to 1.3 and 1.2...
Make sure that your commit contains solely the bug fix (commit early and often is the open source way). Then just merge it normally into 1.3 and 1.2 with 'svn merge'. As long as the revision is noted in the commit log together with the svn command used, accounting is easy enough. You just have to be very careful not to port the 1.3 line revision containing the ported revision back into the 'test_suite' branch. Oh, it's best to also quickly describe at the end of the commit log what the ported revision does. That way when I make the new release, I may not need to look at the subversion log of the branch to make the relax release notes.
Cheers,
Edward