by, 11-06-2011 at 06:41 PM (1671 Views)
SVN (SubVersion) is being used in software development houses to maintain the source code. Its very effective if used properly. In this post, I will present some basic concepts about SVN.
Usually, SVN has following directory structure:
You may add more directories like archive and some other of you want. I will explain the use of above directories so you know when to use what.
The trunk directory contains main line of development. If you need to checkout a project, you will do from here. The project copy from trunk is later released to the client.
Branch is a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. A branch always begins life as a copy of something, and moves on from there, generating its own history. For example, you may create a branch from trunk. You might be thinking, why we need that. Let me explain:
You are working on a project and you are assigned a task which can take 10 days. You want to check in your changes to the trunk, once the task is full done because intermediate changes might not be very interesting and may introduce problems for others. If you simply don’t check in, then its risky to keep the development only on you machine. The solution is to create a branch and work keep checking in to that. In this way, you will have all your work in the repository and it won’t be bothering any one.
Another important concept is that of tags. Tags (as Branches) are ordinary directories that are created by copying. The thing is, what meaning you attach to it. The reason of creating a directory as a “tag” is to create a snapshot. As long as nobody ever commits to the directory, it forever remains a snapshot. That’s the difference between branch and tag. In tag, developers do not commit any thing. Its sort of release.
The typical way how SVN is used in software development and maintenance is as follows:
procedure looks like this:
Day-to-day changes are committed to /trunk which involves new features and bugfixes.
Then the management thinks that the project is ready to be released, the trunk is copied to a “release” branch (/branches/1.0). A team of software testers starting testing the release branch and the other team continues adding new features in the trunk branch for future releases. If bugs are found, corrections are made and ported in branch and in trunk as well.
At a stage, the branch/1.0 will be tagged and released. It will be tagged to /tags/1.0.0 as a reference snapshot. This will be packaged and released to customers.
The branch is now maintained over time. The bugfixes are continued to be ported into branch and trunk. When enough bugfixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.