Updating a Baselibs Component: Difference between revisions

Line 13:

$ bcvs tag -d Internal-3_3_1

=== ~~Importing NCO 4.2.3~~ ===

=== Unpack the new library ===

~~4. Move~~ to ~~/gpfsm/dswdev/mathomp4/Baselibs/NewImports~~

First, move to a directory that can contain your "new import",

$ cd /~~gpfsm~~/~~dswdev~~/mathomp4/Baselibs/NewImports

$ cd /discover/swdev/mathomp4/Baselibs/NewImports

~~a. Untar nco-4.2.3.tar.gz~~ (from http://nco.sourceforge.net/#Source)

untar the package (from http://nco.sourceforge.net/#Source),

$ tar xzf nco-4.2.3.tar.gz

~~b. Move~~ into ~~netcdf~~ directory:

and move into the new directory directory:

$ cd nco-4.2.3/

~~c. Test~~ import ~~netcdf~~ package

=== Import the new package ===

First, do a dry-run import of the package (note the <tt>-nq</tt>):

$ bcvs -nq import -kk -m 'MAT: import NCO 4.2.3 retrieved 2012-NOV-13 from http://nco.sourceforge.net/#Source' Baselibs/src/nco NCO release-4_2_3

~~d. Really~~ import the package

If everything looks okay, then actually import the package:

$ bcvs import -kk -m 'MAT: import NCO 4.2.3 retrieved 2012-NOV-13 from http://nco.sourceforge.net/#Source' Baselibs/src/nco NCO release-4_2_3

Line 40:

Line 42:

cvs -d :ext:mathomp4@progressdirect:/cvsroot/baselibs checkout -j<prev_rel_tag> -jrelease-4_2_3 Baselibs/src/nco

e. ~~Check~~ out ~~model anew~~

Note that this command provides helpful information on how to merge this package. You'll want to make a note of the previous release tag. The best way to find this out is via tkcvs, in my opinion.

=== Merging the new package into the tree ===

First, check out a new Baselibs tree:

$ cd /discover/swdev/mathomp4/Baselibs

Line 49:

Line 55:

$ bcvs -q checkout -kk Baselibs/src/nco

f. ~~Update~~ to new release

Note, I'm not too sure why you do the package checkout right after the full Baselibs checkout (which would checkout the HEAD), but Denis always did this. It can't hurt, though. Note also that we checkout ignoring keywords (<tt>-kk</tt>) which always makes merging easier.

Then, checkout/update to new release:

$ bcvs -nq update -kk -jrel-4_0_3-20100627 -jrelease-4_2_3 Baselibs/src/nco

(remove -nq and run again once satisfied)

and remove -nq and run again once satisfied. ''Note: Denis used this style of command, but CVS prefers checkout. Unsure which is better.''

g. Move into ~~nco~~

Move into the new package directory:

$ cd Baselibs/src/nco

~~h. Check~~ for conflicts

and check for conflicts:

$ bcvs -nq upd -kk | grep -r '^[C|M]'~~TmpBaselibs~~

$ bcvs -nq upd -kk | grep -r '^[C|M]'

cvs update: New directory `autom4te.cache' -- ignored

Line 105:

Line 113:

M man/ncwa.1

i. ~~Fix~~ conflicts

Note in this case that no conflicts were found. If there were conflicts, you should resolve them. When in doubt, I suggest always using '''only''' what the new package contained. The only exceptions might be in Makefiles or other files that might have been edited by Denis or other maintainers to get it to build with the other Baselibs. But, if at all possible, go with the stock library.

~~No conflicts found.~~

Once all is good, commit the changes:

j. ~~Commit changes~~

$ bcvs commit -m "MAT: merge new NCO release 4.2.3, no conflicts found"

~~$ bcvs commit -m "MAT: merge~~ new ~~NCO~~ release ~~4.2.3, no conflicts found"~~

=== Tagging your new release ===

~~5. Tag~~ new ~~release~~ at src level

To make your new tag, first do a relative tag at the <tt>src/</tt> level:

$ cd ..

$ bcvs tag -r GMAO-Baselibs-3_3_0 Internal-3_3_1

~~6. UNTAG nco~~ and retag the new vendor release

Then, for safety's sake, '''untag''' the new library and retag the against the new vendor release tag:

$ cd nco/

Line 124:

Line 132:

$ bcvs tag -r release-4_2_3 Internal-3_3_1

~~7. Edit~~ Changelog and VERSION and commit

Next, edit the usual metafiles (<tt>Changelog</tt>, <tt>CONTENTS</tt>, and <tt>VERSION</tt>) as well as any needed make system changes and commit those on the HEAD. Then, push your new tag on those files:

8. ~~Push~~ tag on ~~new~~ files

~~$ bcvs tag -F Internal-3_3_1 ChangeLog INSTALL VERSION~~

~~11. Checkout new~~ tag ~~and build~~

$ bcvs tag -F Internal-3_3_1 ChangeLog CONTENTS VERSION

~~a. Try doing a cvscmp to the "before"~~ tag~~. Make sure the difference~~

=== Verify new tag ===

~~looks okay~~

12. ~~If all works, delete~~ the ~~"before"~~ tag

The final step is to checkout the new tag and build the Baselibs per usual. My first step is to usually do a <tt>cvscmp</tt> against the old tag to make sure everything looks sane. I then like to do a <tt>diff -r</tt> between the updated library and the stock package that was downloaded from the web. Hopefully, all is well.

~~13.~~ If all *really* works, rename Internal~~-3_3_1 to~~ GMAO-Baselibs~~-3_3_1~~

If everything works, you can then delete your "before" tag and if all '''really''' works, rename the <tt>Internal</tt> tag with an official <tt>GMAO-Baselibs</tt> tag.

[[Category:Baselibs|Updating]]

@@ Line 13: / Line 13: @@
     $ bcvs tag -d Internal-3_3_1
-=== Importing NCO 4.2.3 ===
+=== Unpack the new library ===
-. Move to /gpfsm/dswdev/mathomp4/Baselibs/NewImports
+First, move to a directory that can contain your "new import",
-    $ cd /gpfsm/dswdev/mathomp4/Baselibs/NewImports
+    $ cd /discover/swdev/mathomp4/Baselibs/NewImports
-a. Untar nco-4.2.3.tar.gz (from http://nco.sourceforge.net/#Source)
+untar the package (from http://nco.sourceforge.net/#Source),
     $ tar xzf nco-4.2.3.tar.gz
-b. Move into netcdf directory:
+and move into the new directory directory:
     $ cd nco-4.2.3/
-c. Test import netcdf package
+=== Import the new package ===
+First, do a dry-run import of the package (note the <tt>-nq</tt>):
     $ bcvs -nq import -kk -m 'MAT: import NCO 4.2.3 retrieved 2012-NOV-13 from http://nco.sourceforge.net/#Source' Baselibs/src/nco NCO release-4_2_3
-d. Really import the package
+If everything looks okay, then actually import the package:
     $ bcvs import -kk -m 'MAT: import NCO 4.2.3 retrieved 2012-NOV-13 from http://nco.sourceforge.net/#Source' Baselibs/src/nco NCO release-4_2_3
@@ Line 40: / Line 42: @@
           cvs -d :ext:mathomp4@progressdirect:/cvsroot/baselibs checkout -j<prev_rel_tag> -jrelease-4_2_3 Baselibs/src/nco
-e. Check out model anew
+Note that this command provides helpful information on how to merge this package. You'll want to make a note of the previous release tag. The best way to find this out is via tkcvs, in my opinion.
+=== Merging the new package into the tree ===
+First, check out a new Baselibs tree:
     $ cd /discover/swdev/mathomp4/Baselibs
@@ Line 49: / Line 55: @@
     $ bcvs -q checkout -kk Baselibs/src/nco
-f. Update to new release
+Note, I'm not too sure why you do the package checkout right after the full Baselibs checkout (which would checkout the HEAD), but Denis always did this. It can't hurt, though. Note also that we checkout ignoring keywords (<tt>-kk</tt>) which always makes merging easier.
+Then, checkout/update to new release:
     $ bcvs -nq update -kk -jrel-4_0_3-20100627 -jrelease-4_2_3 Baselibs/src/nco
-   (remove -nq and run again once satisfied)
+and remove -nq and run again once satisfied. ''Note: Denis used this style of command, but CVS prefers checkout. Unsure which is better.''
-g. Move into nco
+Move into the new package directory:
     $ cd Baselibs/src/nco
-h. Check for conflicts
+and check for conflicts:
-    $ bcvs -nq upd -kk | grep -r '^[C|M]'TmpBaselibs
+    $ bcvs -nq upd -kk | grep -r '^[C|M]'
     cvs update: New directory `autom4te.cache' -- ignored
@@ Line 105: / Line 113: @@
     M man/ncwa.1
-i. Fix conflicts
+Note in this case that no conflicts were found. If there were conflicts, you should resolve them. When in doubt, I suggest always using '''only''' what the new package contained. The only exceptions might be in Makefiles or other files that might have been edited by Denis or other maintainers to get it to build with the other Baselibs. But, if at all possible, go with the stock library.
-   No conflicts found.
+Once all is good, commit the changes:
-j. Commit changes
+   $ bcvs commit -m "MAT: merge new NCO release 4.2.3, no conflicts found"
-   $ bcvs commit -m "MAT: merge new NCO release 4.2.3, no conflicts found"
+=== Tagging your new release ===
-. Tag new release at src level
+To make your new tag, first do a relative tag at the <tt>src/</tt> level:
     $ cd ..
     $ bcvs tag -r GMAO-Baselibs-3_3_0 Internal-3_3_1
-. UNTAG nco and retag the new vendor release
+Then, for safety's sake, '''untag''' the new library and retag the against the new vendor release tag:
     $ cd nco/
@@ Line 124: / Line 132: @@
     $ bcvs tag -r release-4_2_3 Internal-3_3_1
-. Edit Changelog and VERSION and commit
+Next, edit the usual metafiles (<tt>Changelog</tt>, <tt>CONTENTS</tt>, and <tt>VERSION</tt>) as well as any needed make system changes and commit those on the HEAD. Then, push your new tag on those files:
-. Push tag on new files
-   $ bcvs tag -F Internal-3_3_1 ChangeLog INSTALL VERSION
-. Checkout new tag and build
+   $ bcvs tag -F Internal-3_3_1 ChangeLog CONTENTS VERSION
-   a. Try doing a cvscmp to the "before" tag. Make sure the difference
+=== Verify new tag ===
-      looks okay
-. If all works, delete the "before" tag
+The final step is to checkout the new tag and build the Baselibs per usual. My first step is to usually do a <tt>cvscmp</tt> against the old tag to make sure everything looks sane. I then like to do a <tt>diff -r</tt> between the updated library and the stock package that was downloaded from the web. Hopefully, all is well.
-. If all *really* works, rename Internal-3_3_1 to GMAO-Baselibs-3_3_1
+If everything works, you can then delete your "before" tag and if all '''really''' works, rename the <tt>Internal</tt> tag with an official <tt>GMAO-Baselibs</tt> tag.
 [[Category:Baselibs|Updating]]