Source code Changes To
From revision 31 to 32:
--- scm.md (revision 31)
+++ scm.md (revision 32)
@@ -1,14 +1,99 @@
-## Checking Out the Sources
+### Checking Out the Tyrus Sources
+Tyrus uses GIT version control system and this fact allowed us to have the project sources available
+on [GitHub][tyrusgh]. The repository can be cloned
+in a read-only mode by invoking:
-Tyrus is hosted on [java.net](http://java.net) and source code is stored in SVN repository.
+git clone email@example.com:tyrus-project/tyrus.git
+If you're only interested in reading the latest version of the sources and do not wish
+to a) contribute code back to the repository or b) do not care about the history,
+you can speed up the clone process by invoking:
-[Tyrus SVN repository](https://java.net/projects/tyrus/sources/source-code-repository/show)
+git clone --depth 1 firstname.lastname@example.org:tyrus-project/tyrus.git
+instead. This may speed up the clone process considerably.
+### Understanding Tyrus Branches and Tags
-Read-only copy can be obtained by executing command
+Tag & Branch information:
-svn checkout https://svn.java.net/svn/tyrus~source-code-repository/trunk
\ No newline at end of file
+Tag/Branch Name | Details
+--- | ---
+[master][tyrusgh] | This is effectively Tyrus development branch ("trunk" in SVN terms).
+[1.0](https://github.com/tyrus-project/tyrus/releases/tag/1.0) | This is the Tyrus 1.0 release tag. A sustaining branch for Tyrus 1.0 release will be created from the tag if necessary. [Fixed issues](https://java.net/jira/browse/TYRUS/fixforversion/16078).
+[1.1](https://github.com/tyrus-project/tyrus/releases/tag/1.1) | This is the Tyrus 1.1 release tag. A sustaining branch for Tyrus 1.1 release will be created from the tag if necessary. [Fixed issues](https://java.net/jira/browse/TYRUS/fixforversion/16467).
+[1.2](https://github.com/tyrus-project/tyrus/releases/tag/1.2) | This is the Tyrus 1.2 release tag. A sustaining branch for Tyrus 1.2 release will be created from the tag if necessary. [Fixed issues](https://java.net/jira/browse/TYRUS/fixforversion/16550).
+[1.2.1](https://github.com/tyrus-project/tyrus/releases/tag/1.2.1) | This is the Tyrus 1.2.1 release tag. A sustaining branch for Tyrus 1.2.1 release will be created from the tag if necessary. [Fixed issues](https://java.net/jira/browse/TYRUS/fixforversion/16601).
+In order to check out a branch in git, you simply need to issue
+`git checkout <branch name>` (e.g. `git checkout master`).
+If you're interested in working with an existing tag, you'll first need to issue
+`git fetch --tags` in order to obtain the tag references. After successful completion
+of this command, you can issue `git checkout <tag name>`. Note that when doing so, you'll
+get a message about being in a detached state - this is normal and nothing to worry about.
+All fetched tags can be listed using `git tag -l` In general, we keep our tag names
+inline with the released version. For example, if you wanted to checkout the tag
+for Tyrus 1.0, the tag name would be *1.0* This convention is consistent for
+### Submitting Patches and Contribute Code
+Contributing to Tyrus project can be done in various ways: bug fixes, enhancements, new features,
+or even whole new extension modules. In general, all contributions must comply with following
+* All contributors must sign the [Oracle Contributor Agreement][oca].
+* Any new contribution must be associated with an existing [Tyrus issue][tyrus-jira].
+ If no existing issue has been yet opened for the problem your contribution attempts to solve,
+ please open a new one.
+* All bug fixes must be accompanied with a new unit test (or a set of unit tests) that
+ reproduce the fixed issue.
+* New large feature contributions must be accompanied with:
+ * A patch for [Tyrus User Guide][tug-sources] that is written in DocBook 5. Either a
+ new chapter or a new section to existing chapter must be provided as appropriate.
+ * At least one new [example][tyrus-examples] demonstrating the feature.
+For small patches (minor bug fixes, correction of typos in documentation etc.), linking a
+[gist][gist] that contains your patch with details on what you\'re resolving and how you\'ve
+resolved it is most convenient approach. Alternatively, especially in case of larger contributions
+or more significant changes in code, please follow the process of opening a new
+[GitHub pull request][gpr].
+### GIT Tips and Tricks for Developers
+First, for anyone not familiar with Git, before attempting to work with the repository,
+we highly recommend reading the [Git tutorial][gitorial].
+When collaborating, before you push your changes to the remote repository, it's best
+to issue `git pull --rebase` This will 'replay' any changes that have occurred in the
+remote repository since your last pull on top of your current work. If you don't do this,
+Git will perform a merge for you, however, the result of the commit will look like
+you've touched files that you haven't. This is fine, but it generally raises a few eyebrows
+and makes code reviews of any patches slightly more complicated. As usual, more complications
+means more time spent in review.
+There are times when you may need to move changes back and forth between branches.
+In cases where the code bases are very similar, you can use
+`git cherry-pick <SHA1 of the commit to pick and apply>` to do this quickly.
\ No newline at end of file