I think we sould consider using some sort of version control system for distributing ROMS. This would be useful, because users could fix bugs in the code, and the code that we download could also be bug free. The second thing is a big deal for me. Every time I want to start over with ROMS, I need to fix a series of bugs before the thing will work. These bugs are all minor, and known, but it is still a pain.
I would like to suggest that we use monotone. This program has a number of advantages, that seem well suited for the sorts of things we do, including being distributed, secure, dealing with entire directory trees, and allowing for a number of branches. I have begun to test this program, and it seems relatively easy to use, and very powerful. I have written a brief totorial on how to use this program for ROMS on my blog. My tutorial is heavily based on the tutorial from the monotone web page.
If someone has a better suggestion, I would love to hear it. Even getting a fresh, bug free version of ROMS over CVS would be an improvement.
-Rob
Using a version control system for ROMS.
Oh, man, I just heard about subversion ( http://subversion.tigris.org/ ) and was going to investigate that. Have you compared them? Is monotone better?
Monotone vs. subversion.
Subversion seems to be the hippest CVS replacement, and many thought it should be used for the Linux source code (which used BitKeeper, until recently...). In the discussions on slashdot about replacing BitKeeper, I found some comments about monotone that seemed positive, so I checked it out and liked it.
You can compare all of the different systems here. Both Subversion and monotone have all of the features that we would need for development of a model like ROMS. Subversion has some extra features that sound nice, like tracking changes to a person lineby line. I like monotone because it is relatively simple to use (Steve Baum has looked at subversion, and says that it is pretty complicated), and very flexible. I think simplicity is crutial, if we want people to adopt a VCS -- perhaps even monotone is too complicated for most users...
I have improved my tutorial for using monotone with ROMS, and at least sucking down the code is straightforward (as straightforward as cvs, at least). Syncing with a reposatory is only slightly more complicated, as it involves generating and exchanging public keys. Setting up a server is the most complicated, but fortunately, this only needs to be done by one group.
I would suggest using both cvs and monotone for download only, but use monotone for code developement.
You can compare all of the different systems here. Both Subversion and monotone have all of the features that we would need for development of a model like ROMS. Subversion has some extra features that sound nice, like tracking changes to a person lineby line. I like monotone because it is relatively simple to use (Steve Baum has looked at subversion, and says that it is pretty complicated), and very flexible. I think simplicity is crutial, if we want people to adopt a VCS -- perhaps even monotone is too complicated for most users...
I have improved my tutorial for using monotone with ROMS, and at least sucking down the code is straightforward (as straightforward as cvs, at least). Syncing with a reposatory is only slightly more complicated, as it involves generating and exchanging public keys. Setting up a server is the most complicated, but fortunately, this only needs to be done by one group.
I would suggest using both cvs and monotone for download only, but use monotone for code developement.
-
arango
- Site Admin
- Posts: 1361
- Joined: Wed Feb 26, 2003 4:41 pm
- Location: DMCS, Rutgers University
- Contact:
Users are free to use any version control that they like. Recall that once that you download the code, you are responsible for the changes that you make to your own copy of the code. We are only responsible for the official released version of the code. ROMS/TOMS is both a research and operational model. As a research tool you can make changes to the code to test new ideas and algorithms. Tested new algorithms can be pass back to the developers so we can incorporate such changes to the master code.
We cannot allow users changing the master code at will. Not everybody is fully qualified to do so. As you already know, ROMS/TOMS has already a tangent linear, representer, and adjoint codes. Any change to a single line in the code needs to be propagated appropriately to all those models. The adjoint is exact. This characteristic is needed for the state matrix manipulations in variational data assimilation and Generalized Stability Theory (GST) analysis. It took us four years to get to this point. Any change to model code can set us back months looking for bugs in the debugger. We will need to repeat an extensive suite of tests. We are not in the position to do this every time that a user in the community changes the code. We cannot afford that.
I have to admit that we do not release model versions very frequently. However, it is our experience that users do not like to change the model version unless it offers something attractive for them to change. It is the nature of this business. Therefore, we made the conscious decision of releasing only very stable versions of the model and less frequently. If we release too frequently, we will spend mostly our time answering e-mails and forum postings.
Thank you for your suggestion,
We cannot allow users changing the master code at will. Not everybody is fully qualified to do so. As you already know, ROMS/TOMS has already a tangent linear, representer, and adjoint codes. Any change to a single line in the code needs to be propagated appropriately to all those models. The adjoint is exact. This characteristic is needed for the state matrix manipulations in variational data assimilation and Generalized Stability Theory (GST) analysis. It took us four years to get to this point. Any change to model code can set us back months looking for bugs in the debugger. We will need to repeat an extensive suite of tests. We are not in the position to do this every time that a user in the community changes the code. We cannot afford that.
I have to admit that we do not release model versions very frequently. However, it is our experience that users do not like to change the model version unless it offers something attractive for them to change. It is the nature of this business. Therefore, we made the conscious decision of releasing only very stable versions of the model and less frequently. If we release too frequently, we will spend mostly our time answering e-mails and forum postings.
Thank you for your suggestion,
2.1 has subroutines that have been fixed (for example the wieghts for the 2D stepping) and typos (e.g., #ifdef CANUTO_A || CANUTO_B). Why not fix these things in the standard releases so that everybody doesn't need to discover these things for themselves (or reapply them each time they start from scratch)? You don't need to give all users editing control, you can still have complete control the official, stable releases even if you allow all users to submit changes.
Don't you think the 'stable' versions should have all the discovered bugs fixed?
Don't you think the 'stable' versions should have all the discovered bugs fixed?