The Vivo project is made up of more than one Subversion repository, but they are all treated in the same way when it comes to the trunk, branches, and tags.

The trunk

The trunk is where the majority of development work is done. The code in the trunk is constantly changing, and aiming for the next release of the software. Developers should remember that other developers are checking out code from the trunk all of the time.

Code that is committed to the trunk should not break the build, should not cause the unit tests to fail, and should not break any existing functionality.

Branches for development

If you are working on a large refactoring, you might find that you can’t commit your code without breaking things. In that case, it’s time to create a branch. With your own branch devoted to your task, you can commit code freely without worrying about the impact it will have on other developers.

This will be a development branch, so the name of the branch should start with “dev”. After that, the name can have a very short description of the task, and the key of the associated JIRA issue, if there is one. For example:

When your code reaches a state where you are ready to commit it to the trunk, you can merge from your branch to the trunk. Be sure to test the merged code before committing to the trunk.
When you have finished with your development branch, feel free to delete it.

Branches for maintenance

When an official release is made of any of the Vivo projects, the first step is to create a maintenance branch in the repository. [The second step is to create a tag, but that is discussed in the next section].

The maintenance branch means that developers can continue working in the trunk, committing changes that have nothing to do with the release.

The name of the branch starts with “maint”, and continues with a brief description of the release. So, a maintenance branch for release 1.3 of Vivo would be called:

Since Vitro is used as the basis for other projects, it might have maintenance branches that are specifically for releases of those projects. For example, a maintenance branch of Vitro that was created for release 1.3 of Vivo would be called:

A maintenance branch will never be merged wholesale back into the trunk. If a bug is found as the release is being tested, the fix should be committed to the branch. If the fix is relevant to the trunk, the fix should be merged to the trunk and committed there also.

When testing is complete and the release is announced, the maintenance branch becomes dormant and no more commits are made to it. However, if a “bug-fix” release is planned (for example, 1.3.1), the maintenance branch becomes active again, and bug fixes are applied to the branch. Again, if the changes are relevant to the trunk, they should be merged to the trunk and committed there also.

Tags

A tag represents a fixed point in time. Tags are created to capture the state of the repository when a major event occurs. No changes are ever committed to a tag.

Tags for release candidates or for final releases are named for the release or release candidate they denote. So the tag for the first release candidate of release 1.3 of Vivo would be called:

And the tag for the final release of 1.3 of Vivo would be called:

Again, since releases of Vitro may be made specifically to support releases of other projects, the tag names should contain that information. For example: