diff --git a/bacnet-stack/doc/README.subversion b/bacnet-stack/doc/README.subversion index cbab4aba..4f142fe1 100644 --- a/bacnet-stack/doc/README.subversion +++ b/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. -One of the most important properties is the eol-style property +the appropriate subversion properties are set on newly added files. +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 -section if it already exists, as duplicate section names can +Warning: Make sure the settings are merged into the appropriate +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. \ No newline at end of file diff --git a/bacnet-stack/release-branch.sh b/bacnet-stack/release-branch.sh new file mode 100644 index 00000000..10606aa0 --- /dev/null +++ b/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!"