When we say Subversion, or SVN, every developer who uses it understands what we are going to talk about. SVN should be the de facto element of any development cycle. We can use SVN not only with code files but with any types of files which are involved in the development process (but it is not confined to those files either).

In this article, we will consider how we can use SVN effectively by following a few practices. It will help improve your development workflow and make the final source code more stable. When we say stable, it means it will have fewer conflicts than other approaches, but making it 100% conflict free is near to impossible, because all developers have their own ways of getting work done.

We will be going through the below points in this article:

1. Repository Patterns
2. Repository Elements
   
3. Branch Policy
   
4. A Few Important Practices
   

Repository Pattern

This section deals with the structure of your repository. It can be either a single repository or multiple repositories. Both patterns are widely used in the industry, and both have their own pros and cons. So it's totally up to us which one we should use based on our requirements.

Single Repository Pattern

In this pattern, we should create one repository in the SVN server and keep on adding multiple projects in the same repository. Normally when we are planning to use this pattern we should make a repository without the default repository structure, i.e. no branches, tags or trunk directory. However, this is not mandatory.

There are different ways people are following this pattern—below are a few of them:

Root
 - ProjectA
   - branches
   - tags
   - trunk
 - ProjectB
   - branches
   - tags
   - trunk

Root
 - ClientA
   - ProjectA
     - branches
     - tags
     - trunk
   - ProjectB
     - branches
     - tags
     - trunk
     
 - ClientB
   - ProjectB
     - branches
     - tags
     - trunk
   

This pattern is followed when we have a small group of people working on a few projects and project size is small to medium. This can also be implemented for projects which are related to each other and sharing certain code. This pattern has its own pros and cons which are as mentioned below:

Pros:

• Single place for all code, even for projects which are not related to you.
• Single authorization, because permission needs to be assigned for one repository and the rest are just directories under that.
  
• Less administrative work: a new project can be added without help of an SVN admin because there's no need to create a new repository. From a backup point view, the admin needs to take a backup of only one repository. The entire project can be removed without removing the repository.

Cons:

• As multiple projects are included, dumping and checking out one huge repository can be very time-consuming.
• The revision number applies to the whole repository, so the revision number for the project will keep on increasing (even though no commits have been done on that project) according to commits in other projects.
  
• Branching and tagging becomes a complex process when the number of projects and directories included grows.
  

Multiple Repository Pattern

This pattern is suited for large projects which may or may not relate to each other. As with the previous method, this method also has its own pros and cons, which are as mentioned below:

Pros:

• We can define access permission for all users and projects. So each user will have access to projects for which they are involved.
• Each project will have its own revision number sequence.

Cons:

• SVN is not supported by merging of code from a different repository.

Repository Elements

Any type of repository may contain (but is not limited to) three elements, which are branches, tags and the trunk. There is no such well-set definition on the use of these three elements. We can put it in whatever manner we want. Do you want tags to be your main development line? No problem at all, just go ahead and do that. No one will arrest you.

But their little guidelines evolved based on experience working with SVN, and we have a few guidelines on each of the elements.

Trunk

The trunk is used for the latest/current development line. 

Branches

A branch should be used when we have some significant changes which may interrupt the main development line (trunk). So to work without affecting the trunk, we should create a branch from the trunk and make the required changes in that. Then later, when we are done with the changes, we can merge that branch to the trunk.

Tags

Tags are considered a snapshot of your code at a certain point, e.g. MileStone1, Milestone2, etc.

Branch Policy

We can have a never-ending debate on this topic, because everyone has their own perspective while working with branches in SVN. Each policy has its pros and cons, which we will see in the next section:

Never Branch

In this policy, every developer keeps on working on the trunk only, and no branching and merging is held here. 

Pros:

• Very easy policy to be taken.
• Minimal to no learning curve. Developers have to pass through the process of learning about branching and merging.
  

Cons:

Every developer commits on the trunk so the trunk can be unstable at any time, which can be a bigger issue. 

Always Branch

In this policy, developers can work on every feature on a separate branch rather than on the trunk itself. Once changes are done, it can be reviewed on a branch and later merged with the trunk. 

Pros:

• As each will be developed on a separate branch, the trunk will remain stable at any point in time. Because things are being tested and developed on the branch, the trunk will always have reviewed the code.

Cons:

• Each developer does not have a transparent view of other developers' features, and it may create more conflicts while merging with the trunk.
• More administrative time is required to resolve these conflicts and merge the branch to the trunk.
  

Branch When Needed

In this pattern the user keeps working on the trunk to reduce the amount of branching and merging. But a developer should create a branch when needed. 

How to identify this need? In this case, the developer should ask the question to him/herself: What if my change required multiple changes? If I am going to commit all at once then will it discourage or create a problem for peer review?

If you got a yes answer to any of the above questions then you should create a new branch for that feature and once you are done with feature, it can be merged with the trunk after proper testing on the branch itself.

Pros:

• Compared to "Always Branch", this method has less branching and merging.
• The trunk is guaranteed to be stable at all times.
  

Cons:

• Although it involves less branching and merging, it will add extra tasks for branching, merging, compiling and testing.

Important Tips

Use Hooks

We can use a pre-commit hook to make sure that developers have entered the required commit message. Also we can use a post-commit hook to send email to a higher authority for the code review. 

Stay Up to Date

It's always preferred to update your code to the head to make sure you have the latest code with you. This way it will reduce the chances of conflicts in code and improve stability.

One Thing at a Time

Imagine you have worked on multiple changes and you commit all files in one go, saying you have completed Task 1, Task 2 and Task 3. After a few days, would some other developer be able to determine which files are related to which task? So there's a very simple rule to follow: commit one change at a time rather than committing multiple changes in a single commit.

Make Use of Log Messages

We are human, thus we tend to forget things. So it's always good practice to place a detailed log message while committing any changes in SVN. It will help us to understand what has been committed when, so we can easily revert back to that version by just looking at the log message. Let's look at two different log messages:

1. "Completed Changes": This is incomplete and we are not able to understand what has been committed.
2. "Completed Facebook integration, added Facebook SDK files": This is complete and well detailed. It shows what changes have been made and which dependent files were added.

Commit Often

If you working on a larger task, than it is recommended to commit changes more often while working on that task instead of committing after completion of the task. This practice will help you get into any stage of that particular task.

Backup Repository

Finally a note for SVN administrators, always do regular backups of your repository. This will help you when there is a disaster.

Conclusion

As mentioned earlier in this article, there are no set in stone rules defined for using SVN. So I have tried my best to find some guidelines to work with SVN based on my overall experience.