[Nexus-developers] Roll-back of NeXus source code repository
Jens Krüger
jens_krueger at frm2.tu-muenchen.de
Wed Jun 19 10:24:15 BST 2002
Hi Freddie,
sorry if I generated some confusion with my development trunk called
"add-autotools".
Am Dienstag, 18. Juni 2002 15:57 schrieb Akeroyd, FA (Freddie) :
> At Rays request (so he can make some changes for NeXus 2.0 this week)
> i have restored the NeXus CVS repository from backup
> to its state as of Friday 17th May, which is just prior to the addition
> of the "autotools" branch (the additions since then are currently saved
> elsewhere). To avoid confusion, please do not commit changes from
> any directories that you currently have checked out - instead you
> should check out a new copy to a new directory and then copy across
> any changes you want to make to this new directory before committing.
You are right with your comments to the philosophy of the CVS development.
We should after a released version generate a branch for bugfixing of the
released version.
The main development to a new version should be applied in the main trunk and
therefore it is not neccessary to create a new branch for developments. But
sometimes it seems to be a good idea for developing new features or for
testing new ideas in the development to create a branch. The reason is that
you don't want to disturb the other people in the work (i.e. they want to
prepare a new release, and you want to test some new details or you will
start a redesign of some parts or what ever). If you have a look at the linux
kernel developers. There are a lot of branches for different developers. The
merge features developed in the main trunk in the own branch and vice versa.
You may say, you can do it on my local machine, but you work not allways
alone at this problem. From my point of view we need branches for bugfixes
and for testing.
Furthermore we need a naming convention for these branches to avoid
confusions.
(i.e. release_X_Y_Z for a released version,
branch_bug_fix_release_x_y_z for the bug fix branch, all released bug fixes
should only increase z)
> In the meanwhile, we should probably discuss how we want to proceed
> with a new branch. The general CVS philosophy is that your main
> development should be on the main "trunk" and branches be used for
> (1) Applying bug fixes to a previous version when you are making
> major changes to your main source code
> (2) If you are modifying sources from elsewhere, you put the unmodified
> source
> onto a branch and then your own modifications of the files go onto the
> main
> development trunk. If a new version of the "sources" appears, you also
> put them onto the branch and can then merge differences between the
> old and new sources back onto the main development arm.
>
Last but not least some remarks to the autotools. I think, the addition of
the autotools is neccessary and it belongs to the main trunk (you are right)
But from my point of view there are a lot of changes in the file structure,
so that I decided, to create a branch, to test the addition of autotools
independend from Mark, Uwe, and Ray. My ideas was: Avoid confusions. But I
see I created some.
> With this reasoning shouldn't "autotools" be on the main trunk - not a
> branch?
> We can create a tag and branch for the source code just prior to adding
> the "autotools" development in case we want to bugfix/ship an update to the
> previous NeXus code?
At this time I mostly of the addition of autotools have done. The main point
in the TODO list is the integration of the F9X compiler. On my machine I'm
using the NAGware f95 compiler. I need a special option for compiling the f90
sources. Who uses other compiler and what options are used?
If you are interested in the current state of adding autotools you may get a
tar ball.
>
> Regards,
>
> Freddie
Regards,
Jens
--
Jens Krüger
Technische Universität München
ZWE FRM-II
Lichtenberg-Str. 1
D-85747 Garching
Tel: + 49 89 289 14 716
Fax: + 49 89 289 14 666
mailto:jens_krueger at frm2.tu-muenchen.de
http://www.frm2.tu-muenchen.de
More information about the NeXus-developers
mailing list