On 2007-05-21 22:58-0400 Hazen Babcock wrote: > > On May 20, 2007, at 7:48 PM, Alan W. Irwin wrote: >> When the time comes, let me know if there is any way I can help you >> further >> (especially with any of the shell scripts that need modification) with the >> changes imposed on the release process by svn. > > Ok. Could you make the following changes to scripts/make_tarball.sh? > 1) Remove the archive tagging stuff. > 2) Uses svn export on a local directory to create the build directory.
I have modified that script, but I have done things a little differently than you requested. I assume you commit your (possibly updated, but that is rare) tags subdirectory before executing the script. Then "svn export" is used to get this tags subdirectory from the SourceForge svn repository. This procedure unequivocally assures that the release tarball can be completely generated from the particular tags subdirectory for the svn repository and not just from your local disk. N.B. I didn't have time to test my script changes which are fairly extensive, but the good news is the script is somewhat simpler now, and hopefully you should be able to understand it completely. If you are wondering how to debug bash scripts, you can dump out everything as it executes by temporarily changing the start line from #!/bin/bash to #!/bin/bash -x > As outlined in README.Release_Manager_Cookbook, the new approach is going to > be create a branch in the tags directory for the release. I prefer the terminology "tag" for each particular subdirectory of tags while "branch" should be reserved for subdirectories of the branches subdirectory. Although the branches and tags subdirectories both just contain svn subdirectories where you can execute any svn command, there is an important convention that distinguishes between them. A tag subdirectory is meant to be a historical snapshot so it is rarely if ever changed (since that destroys history). Tags are cheap in svn (they apparently are done with the equivalent of symlinks) so there should be a separate tag for each SourceForge release tarball that you make. So, for example, if you release both an RC1 tarball and the final tarball at SF for a given release, then there should be two separate tags that correspond exactly to the release tarballs and which should never be changed after those tarballs are publicly made available. In contrast to tags subdirectories, branches subdirectories are expected to be changed a lot with many different commits as development occurs for the branch. > The rest of the > release build process will then be done working off the contents of this > directory. When the release checks out the RM will commit this directory to > Sourceforge. I assume you should commit it when you first create it with the svn copy command and after updates which should be rarely necessary since you are working with a copy of trunk that presumably has been thorougly tested by our core developers. The only exception to this "no updates for tags rule" I can think of is if you forget some part of the release process (e.g., updating a release file) that you catch before you release the tarball at SourceForge. In that special case the additional commit required before running the make_tarball.sh script would be quite fast since typically only one file will be changed. By the way, I think you forgot to comment about the tag commit step in your README.Release_Manager_Cookbook changes. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
