How to use SVN, Branch? Tag? Trunk?

Question

I was googling around a little bit and couldn't find a good "beginners" guide to SVN, not in the meaning of "how do I use the commands" rather; How do I control my source code?

What I'd like to clear up is the following topics:

• How often do you commit? As often as one would press Ctrl + s?
• What is a Branch and what is a Tag and how do you control them?
• What goes into the SVN? Only Source Code or do you share other files here aswell? (Not considered versioned files.. )

I don't have any idea what branch and tag is so I don't know the purpose, but my wild guess is that you upload stuff to the trunk and when you do a major build you move it to the branch? So, what is considered a major build in this case?

Answer 1

A lot of good comments here, but something that hasn't been mentioned is commit messages. These should be mandatory and meaningful. Especially with branching/merging. This will allow you to keep track of what changes are relevant to which bugs features.

for example svn commit . -m 'bug #201 fixed y2k bug in code' will tell anyone who looks at the history what that revision was for.

Some bug tracking systems (eg trac) can look in the repository for these messages and associate them with the tickets. Which makes working out what changes are associated with each ticket very easy.

Answer 2

The subversion book is an excellent source of information on strategies for laying out your repository, branching and tagging.

See also:

Do you continue development in a branch or in the trunk

Branching strategies

Answer 3

Here are a few resources on commit frequency, commit messages, project structure, what to put under source control and other general guidelines:

• Best Practices of Version Control (my own blog)
• Check in Early, Check in Often (Coding Horror) (comments here contain a lot of good advice)
• KDE's commit policy

These Stack Overflow questions also contain some useful information that may be of interest:

• Organizing the source code base when mixing two or more languages (like Java and C++)
• Suggestions for a good commit message: format/guideline?
• How often to commit changes to source control?
• Learning Version Control, and learning it good

Regarding the basic Subversion concepts such as branching and tagging, I think this is very well explained in the Subversion book.

As you may realize after reading up a bit more on the subject, people's opinions on what's best practice in this area are often varying and sometimes conflicting. I think the best option for you is to read about what other people are doing and pick the guidelines and practices that you feel make most sense to you.

I don't think it's a good idea to adopt a practice if you do not understand the purpose of it or don't agree to the rationale behind it. So don't follow any advice blindly, but rather make up your own mind about what you think will work best for you. Also, experimenting with different ways of doing things is a good way to learn and find out how you best like to work. A good example of this is how you structure the repository. There is no right or wrong way to do it, and it's often hard to know which way you prefer until you have actually tried them in practice.

Answer 4

The policy at our work goes like this (multi-developer team working on object oriented framework):

• Update from SVN every day to get the previous day's changes

• Commit daily so if you are sick or absent next day(s) someone else can easily take over from where you left off.

• Don't commit code that breaks anything, since that will impact the other developers.

• Work on small chunks and commit daily WITH MEANINGFUL COMMENTS!

• As a team: Keep a Development branch, then move pre-release code (for QA) into a Production branch. This branch should only ever have fully working code.

Answer 5

The TortoiseSVN TSVN Manual is based on subversion book, but available in a lot more languages.

Answer 6

Version Control with Subversion is the guide for beginners and old hands alike.

I don't think you can use Subversion effectively without reading at least the first few chapters of this.