SVN guide

We recommend using SVN version 1.4.5 or later.

IME: 

Our IME source code repository is at svn+ssh://svn.mit.edu/zest/thalia-maven. The trunk is at the trunk subdirectory and branches are kept in the branches directory. The current branches are thalia1.0-sprint1. Older branches are at svn+ssh://svn.mit.edu/zest/thalia-branches with the following branches:

v0.1.0-pre-REST: the branch before we restified the IME.

v0.1.1-pre-alfresco: the branch before we moved our repository to Alfresco (was using fedora).

limited-release-code-freeze: limited release code freeze in August

limited-release: the actual release

UI: 

Our UI source code repository is at svn+ssh://svn.mit.edu/zest/thalia/laszlo. It has the UI trunk

The UI branches are at svn+ssh://svn.mit.edu/zest/thalia-branches. The UI was originally combined with the IME, so it uses the same old branches as listed above. In September 2007, the UI and IME source code was separated and the UI has its own branches. The current ones are: thalia-UI1.0-sprint1.

SVN Branching Guildline:

We deploy from branches, not the trunk. All new development should happen in the trunk (if you are experimenting something that will drastically change our code base, it is ok to create a branch for it. That branch can be abandoned if the experiment didn't come through. Or merged back into the trunk if the experiment is successful). When a deployment is desired, the trunk is branched. The branch is named release version + sprint # (eg, release1.0-sprint1). That branch is deployed onto the test server. The developers should work with the QA people to bring the branch up to release quality and no new features is allowed to be commited to the branch. Once the work is complete, the branch is deployed into production and the bug fixes in the branch is merged back into the trunk. During the QA process,  new development should be continued at the trunk as before, without affecting the deployment effort.

SVN Best Practices:

Frequent checkins: It is much easier to review and integrate code if it is checked in in small chunks.  A new feature or a bug fix will often take days or maybe weeks to complete, but you should typically be checking in at least one piece of the feature per day if there are a lot of code changes.

Fine grained commits: Don't commit unrelated changes together with a fix.
Be responsible: Always check what you're committing: make sure you're only committing what you need. Do a svn diff of the files you're going to commit and check the changes.
Never break the build: Do not commit code that would break the compile. Try to build your sources and make sure that you add all the new files before you do a commit.
Document your commit: Always add a message with a meaningful explanation about the commit. Always mention the JIRA issue that is related to your commit.

Always follow these steps when committing changes:

Update to latest revision (svn update)
Resolve conflicts
Inspect merged files
Build, test, and fix
Make sure new files get added, removed files deleted (svn status, svn add, svn delete)
Update again (to make sure no one else committed since last update)
Commit with useful message

And never commit more than one feature/fix per commit. Otherwise merging branches becomes painful.

Commit messages & bugs:

We should use the SVN support in Mingle and Jira (Jira via plugin) to aggregate related commits and allow easy browsing of all modifications to our source. Doing so requires a few things:

1. Every commit needs to be related to an issue in Jira. So before any commit, if the appropriate issue doesn't exist in Jira, open an issue in Jira for that feature/bug fix.
2. In your commit message, include the issue's Jira name.
3. In Jira, note which rev in SVN mentions the issue.

Ex: Justin wants to commit the ability to delete images from slideshows. If that doesn't exist in Jira, he creates a new issue (TH-XXX) and links the main slideshow issue as being dependent on TH-XXX. Then he includes "TH-XXX" somewhere in his commit message.

Merging: a Thalia specific version of the SVN guide

To merge a branch back to the trunk:

1. Check out the trunk.
svn checkout svn+ssh://svn.mit.edu/zest/thalia/ui/trunk

2. Find out when the branch was created.
svn log --stop-on-copy svn+ssh://svn.mit.edu/zest/thalia/ui/branches/thalia-UI1.0-sprint4 | grep '^r' | tail -n 1

3. Merge branch changes into local copy of trunk (foo == last rev listed by the above svn log).
cd working/copy/of/trunk
svn merge -r foo:HEAD svn+ssh://svn.mit.edu/zest/thalia/ui/branches/thalia-UI1.0-sprint4

4. Inspect merged files and resolve conflicts.

5. Commit changes to trunk, noting in the log message the range of revisions merged.
svn commit -m "Merged sprint 1 branch r123 - 456 into trunk."

Note: If a branch was merged with the trunk at some point in the past, foo above is the rev of the last merge. Do a find for "Merged" instead of looking at the end of the log.

Backing out changes:

Given a rev 'foo' that you want to undo:

cd working/copy/
svn merge -c -foo .
svn commit -m "Backing out change foo"

The '-' before foo is important. From svn help merge:

-c [--change] arg : the change made by revision ARG (like -r ARG-1:ARG)
If ARG is negative this is like -r ARG:ARG-1