Added Subversion workflow details in README.subversion

Added script to ease branch releases.

bacnet-stack/doc/README.subversion

@@ -1,25 +1,27 @@
+========== Using Subversion to get the BACnet Stack source code ==========
 To check out the trunk from the subversion repository,
 use "svn co", e.g.
 
     svn co https://bacnet.svn.sourceforge.net/svnroot/bacnet/trunk/bacnet-stack/
 
     or for the stable releases:
-    
+
     svn co https://bacnet.svn.sourceforge.net/svnroot/bacnet/tags/bacnet-stack-0-4-0/
 
+========== Configure your Subversion Client for EOL properties ==========
 Committers need to properly configure their svn client so that
-the appropriate subversion properties are set on newly added files. 
+the appropriate subversion properties are set on newly added files.
-One of the most important properties is the eol-style property 
+One of the most important properties is the eol-style property
 that configures OS-specific line-endings for text files.
 
-Add the configuration text below to your subversion client 
+Add the configuration text below to your subversion client
 configuration file that is normally in the following location:
 
 Windows: %USERPROFILE%\Application Data\Subversion\config
 Linux:   ~/.subversion/config
 
-Warning: Make sure the settings are merged into the appropriate 
+Warning: Make sure the settings are merged into the appropriate
-section if it already exists, as duplicate section names can 
+section if it already exists, as duplicate section names can
 cause problems.
 
 [auto-props]
@@ -77,9 +79,54 @@ Makefile = svn:eol-style=native
 *.vcproj = svn:eol-style=CRLF
 
 To test the properties of a file:
-$ svn proplist 
+$ svn proplist
 
-If a file slips into subversion without the eol-style property set, 
+If a file slips into subversion without the eol-style property set,
 you can periodically run:
 $ svn propset svn:eol-style native *
 $ svn commit -m "changed eol-style"
+
+========== BACnet Stack source code management workflow  ==========
+From http://stackoverflow.com/questions/16142/what-do-branch-tag-and-trunk-really-mean
+Paraphrased and copied from gregmac:
+
+We working on what will be 1.0.0 in trunk. Once 1.0.0 is finished,
+branch trunk into a new "bacnet-stack-1.0.0" branch,
+and create a "1.0.0" tag.  Work on what will eventually be 1.1.0 continues
+in trunk.
+
+When you come across some bugs in the code, fix them in the trunk.
+Then merge the fixes over to the 1.0.0 branch. You may also get bug
+reports for 1.0.0, and fix the bugs in the 1.0.0 branch, and then merge
+them back to trunk. Sometimes a bug can only be fixed in 1.0.0 because
+it is obsolete in 1.1.0. It doesn't really matter, the only thing is
+you want to make sure that you don't release 1.1.0 with the same bugs
+that have been fixed in 1.0.0. Once you find enough bugs
+(or maybe one critical bug), you decide to do a 1.0.1 release.
+So you make a tag "1.0.1" from the 1.0.0 branch, and release the code.
+At this point, trunk sill contains what will be 1.1.0, and
+the "1.0.0" branch contains 1.0.1 code. The next time you release an
+update to 1.0.0, it would be 1.0.2.
+
+Eventually you are almost ready to release 1.1.0, but you want to do
+a beta first. In this case, you likely do a "1.1.0" branch, and
+a "1.1beta1" tag. Now, work on what will be 1.2.0 (or 2.0.0 maybe)
+continues in trunk, but work on 1.1.0 continues in the "1.1.0" branch.
+Once you release 1.1.0 final, you do a "1.1.0" tag from the "1.1.0" branch.
+
+You can also continue to maintain 1.0.0 if you'd like, porting bug fixes
+between all 3 branches (1.0.0, 1.1.0, and trunk). The important take
+away is that for every main version of the software you are maintaining,
+you have a branch that contains the latest version of code for that version.
+
+Another use of branches is for features. This is where you branch trunk
+(or one of your release branches) and work on a new feature in isolation.
+Once the feature is completed, you merge it back in and remove the branch.
+The idea of this is when you're working on something disruptive
+(that would hold up or interfere with other people from doing their work),
+something experimental (that may not even make it in), or possibly just
+something that takes a long time (and you're afraid if it holding up a
+1.2.0 release when you're ready to branch 1.2.0 from trunk), you can do
+it in isolation in branch. Generally you keep it up to date with trunk by
+merging changes into it all the time, which makes it easier to re-integrate
+(merge back to trunk) when you're finished.

bacnet-stack/release-branch.sh

@@ -0,0 +1,93 @@
+#!/bin/sh
+# Release helper for this project
+
+PROJECT=bacnet
+SVN_MODULE=bacnet-stack
+FRS_URL=skarg,bacnet@frs.sourceforge.net:/home/frs/project/b/ba/bacnet/bacnet-stack
+
+if [ -z "$1" ]
+then
+  echo "Usage: `basename $0` 0.0.0 0.0.1"
+  echo "Creates the ChangeLog."
+  echo "Creates the release files."
+  echo "Tags this branch release in subversion."
+  exit 1
+fi
+
+# convert 0.0.0 to 0-0-0
+BRANCH_VERSION_DOTTED="$1"
+BRANCH_VERSION_DASHED="$(echo "$1" | sed 's/[\.*]/-/g')"
+TAGGED_VERSION_DOTTED="$2"
+TAGGED_VERSION_DASHED="$(echo "$2" | sed 's/[\.*]/-/g')"
+echo "Creating the ${TAGGED_VERSION_DOTTED} release files for $(BRANCH_VERSION_DOTTED)"
+
+CHANGELOG=ChangeLog-${TAGGED_VERSION_DOTTED}
+echo "Creating the ${PROJECT} change log ${CHANGELOG}"
+rm ${CHANGELOG}
+svn update
+svn log --xml --verbose | xsltproc svn2cl.xsl - > ${CHANGELOG}
+if [ -z "${CHANGELOG}" ]
+then
+echo "Failed to create ${CHANGELOG}"
+else
+echo "${CHANGELOG} created."
+fi
+
+BRANCH_NAME=${SVN_MODULE}-${BRANCH_VERSION_DASHED}
+ARCHIVE_NAME=${SVN_MODULE}-${TAGGED_VERSION_DOTTED}
+TAGGED_NAME=${SVN_MODULE}-${TAGGED_VERSION_DASHED}
+SVN_BASE_URL=https://${PROJECT}.svn.sourceforge.net/svnroot/${PROJECT}
+
+SVN_BRANCH_NAME=${SVN_BASE_URL}/branches/releases/${BRANCH_NAME}
+SVN_TAGGED_NAME=${SVN_BASE_URL}/tags/${TAGGED_NAME}
+echo "Setting a tag on the ${SVN_MODULE} module called ${TAGGED_NAME}"
+svn copy ${SVN_BRANCH_NAME} ${SVN_TAGGED_NAME} -m "Created version ${ARCHIVE_NAME}"
+echo "done."
+
+echo "Getting a clean version out of subversion for Linux gzip"
+svn export ${SVN_TAGGED_NAME} ${ARCHIVE_NAME}
+echo "done."
+
+GZIP_FILENAME=${ARCHIVE_NAME}.tgz
+echo "tar and gzip the clean directory"
+tar -cvvzf ${GZIP_FILENAME} ${ARCHIVE_NAME}/
+echo "done."
+
+if [ -z "${GZIP_FILENAME}" ]
+then
+echo "Failed to create ${GZIP_FILENAME}"
+else
+echo "${GZIP_FILENAME} created."
+fi
+
+echo "Removing the directory exported for Linux."
+rm -rf ${ARCHIVE_NAME}
+
+echo "Getting another clean version out of subversion for Windows zip"
+svn export --native-eol CRLF ${SVN_TAGGED_NAME} ${ARCHIVE_NAME}
+ZIP_FILENAME=${ARCHIVE_NAME}.zip
+echo "done."
+echo "Zipping the directory exported for Windows."
+zip -r ${ZIP_FILENAME} ${ARCHIVE_NAME}
+
+if [ -z "${ZIP_FILENAME}" ]
+then
+echo "Failed to create ${ZIP_FILENAME}"
+else
+echo "${ZIP_FILENAME} created."
+fi
+
+echo "Removing the directory exported for Windows."
+rm -rf ${ARCHIVE_NAME}
+
+echo "Creating ${ARCHIVE_NAME}"
+mkdir ${ARCHIVE_NAME}
+mv ${ZIP_FILENAME} ${ARCHIVE_NAME}
+mv ${GZIP_FILENAME} ${ARCHIVE_NAME}
+mv ${CHANGELOG} ${ARCHIVE_NAME}
+cp readme.txt ${ARCHIVE_NAME}
+
+echo "Sending ${ARCHIVE_NAME} to SourceForge using scp..."
+scp -r ${ARCHIVE_NAME} ${FRS_URL}
+
+echo "Complete!"