bacnet-stack/doc/README.subversion

========== Using Subversion to get the BACnet Stack source code ==========
To check out the trunk from the subversion repository,
use "svn co", e.g.

    svn checkout https://svn.code.sf.net/p/bacnet/code/trunk/bacnet-stack/

    or for the stable releases:

    svn checkout https://svn.code.sf.net/p/bacnet/code/tags/bacnet-stack-0-7-1/

for Anonymous checkout, use http vs. https.

========== 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
that configures OS-specific line-endings for text files.

Add the configuration text below to your subversion client
configuration file that is normally in the following location:

Windows: %USERPROFILE%\Application Data\Subversion\config
or %appdata%\subversion\config
or Click the 'edit' button for 'Subversion configuration file' in
the TortoiseSVN settings dialog under General.

Linux:   ~/.subversion/config or /etc/subversion/config

Warning: Make sure the settings are merged into the appropriate
section if it already exists, as duplicate section names can
cause problems.

[auto-props]
### The format of the entries is:
###   file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?').  All entries which match will be applied to the file.
### Note that auto-props functionality must be enabled, which
### is typically done by setting the 'enable-auto-props' option.
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.h = svn:eol-style=native
*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sh = svn:executable;svn:eol-style=native
*.cmd = svn:mime-type=text/plain;svn:eol-style=CRLF
*.bat = svn:mime-type=text/plain;svn:eol-style=CRLF
Makefile = svn:eol-style=native
*.obj = svn:mime-type=application/octet-stream
*.bin = svn:mime-type=application/octet-stream
*.bmp = svn:mime-type=image/bmp
*.class = svn:mime-type=application/java
*.doc = svn:mime-type=application/msword
*.exe = svn:mime-type=application/octet-stream
*.gif = svn:mime-type=image/gif
*.gz = svn:mime-type=application/x-gzip
*.jar = svn:mime-type=application/java-archive
*.jelly = svn:mime-type=text/plain;svn:eol-style=native
*.jpg = svn:mime-type=image/jpeg
*.jpeg = svn:mime-type=image/jpeg
*.pdf = svn:mime-type=application/pdf
*.png = svn:mime-type=image/png
*.tgz = svn:mime-type=application/octet-stream
*.tif = svn:mime-type=image/tiff
*.tiff = svn:mime-type=image/tiff
*.zip = svn:mime-type=application/zip
*.txt = svn:mime-type=text/plain;svn:eol-style=native
*.xml = svn:mime-type=text/xml;svn:eol-style=native
*.ent = svn:mime-type=text/plain;svn:eol-style=native
*.dtd = svn:mime-type=text/plain;svn:eol-style=native
*.vsl = svn:mime-type=text/plain;svn:eol-style=native
*.xsd = svn:mime-type=text/xml;svn:eol-style=native
*.xsl = svn:mime-type=text/xml;svn:eol-style=native
*.wsdl = svn:mime-type=text/xml;svn:eol-style=native
*.htm = svn:mime-type=text/html;svn:eol-style=native
*.html = svn:mime-type=text/html;svn:eol-style=native
*.css = svn:mime-type=text/css;svn:eol-style=native
*.js = svn:mime-type=text/plain;svn:eol-style=native
*.jsp = svn:mime-type=text/plain;svn:eol-style=native
*.txt = svn:mime-type=text/plain;svn:eol-style=native
*.java = svn:mime-type=text/plain;svn:eol-style=native
*.properties = svn:mime-type=text/plain;svn:eol-style=native
*.sql = svn:mime-type=text/plain;svn:eol-style=native
*.sln = svn:eol-style=CRLF
*.vcproj = svn:eol-style=CRLF

To test the properties of a file:
$ svn proplist

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 are 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.