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: At the end of the day, the code needs to be in a compliable stage and be checked in. A new feature or a bug fix will often take days or maybe weeks to complete.
However, it is important to check in your code frequently so the code is continuous integrated and everybody sees the latest 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. Trying to build your sources and making 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. If you are fixing a bug, remember to put a link to the bug in Jira.
Justin's suggested additions...
Committing: 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.
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.
I'm not sure what Mingle requires, but we would need to include whatever reference it needs as well.