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
Re: Managing the 'test_suite' branch.