Standard practices for Subversion

Question

I\'m wondering if there\'s any other factors to consider for standard practice of using Subversion.

The few I have are:

• Directory structure of /tags /tr

Answer 1

Branches are a good idea for making big, possibly-breaking changes. If trunk is being updated at same time, occasionally merge trunk to branch to keep the branch updated.

Commit an atomic set of related changes. Don't do a big commit with unrelated changes all over. This makes tracking specific changes much easier.

You can have multiple checkouts of the same source - useful if experimenting with unrelated changes.

Avoid committing broken code, or code with failing tests, or with other outstanding issues.

Answer 2

There are many variations in respect to the source code control workflows. The one we are using is the extension of what you are describing in your post. Your workflow is good enough for minor modifications, but not if you have several teams working on different issues of considerable complexity.

What we do is branch out for every team, than the team can commit to the team (project) branch. Every team is also responsible for synchronizing the team branch with the trunk by merging trunk to branch, preferably after every commit to trunk. After the project is completed, the branch is merged back into trunk (re-integrated) and deleted.

This approach branch - merge...merge - merge back - delete works well for us

Answer 3

If you're new to SVN then a good (free) resource is the SVN Book (dead-tree copies can also be bought from O'Reilly).