Manish Agrawal

My Experiments with Technology..

  Home  |   Contact  |   Syndication    |   Login
  102 Posts | 2 Stories | 66 Comments | 12 Trackbacks

News


live stats

Domain Name Free Service
Get a free domain name like www.YourName.co.nr with the following features included: free URL redirection with cloaking, path forwarding, all meta-tags supported, kill-frame feature, NO forced ADS at all, and more.


Google




All content © Manish Agrawal
The content on this site represents my own personal opinions and thoughts at the time of posting, and does not reflect those of my employer's in any way.
Disclaimer:- All postings in this blog is provided "AS IS" with no warranties, and confers no rights.

Article Categories

Archives

Post Categories

Image Galleries

Interesting Blogs

Interesting Links

Mobile

SharePoint

Travel Domain

 

In this article, I have assumed that the reader is aware of the basic functionality of Subversion. This article has been written to make the usage of Subversion more efficient and more effective, as not much information is available on this subject in context of Subversion.

Although most of the things are already mentioned in the Subversion Documentation, but going through such vast information in one go becomes something uncommon. So it is good to have small articles targetting a specific feature which can expose the functionality and will get the attention. Without even any extra effort it gets feeded in mind, making understanding of the subject better.

I installed Subversion and started using it, but I started getting problems in maintenance when the code base spreaded and required maintenance of multiple versions.

To find the solution I studied the documentation available, to use Subversion(SVN) more effectively. One of the important things I read was about "What should be the ideal Repository Structure":

So lets understand the options available:

  • Versioning

In this article I have followed Major.Minor.Build.Revision versioning practice which is very standard, details of it are as under:

In this version number is physically represented as a four-part string with the following format:

        <major>.<minor>.<build>.<revision>

For example, version 1.5.60204.0 indicates 1 as the major version, 5 as the minor version, 60204 as the build         number, and 0 as the revision number.

  • Major: Major releases introduce major new technologies and changes that render previous production releases obsolete.
  • Minor: Minor releases depict feature level enhancements. Addition of features between releases result in incremented minor release.
  • Build: This is auto-generated number, assigned for each build on a day basis. It has YMMDD format, So Feb 04th 2006 shall be 60204.
    Note: Build number for revisions (read bug-fixes to production releases) shall remain same as originally released in production.
  • Revision: This is reset to zero, for each new major/minor version released. For all later bug-fixes, patches to releases that reach production, this number shall sequentially increment.
  • Trunk

Trunk is the main branch of development.

  • Branch

Isolating changes onto a separate line of development is called Branching. Branches are used to try out new feature without disturbing the main line of development. And as the new feature becomes stable the development branch is merged back into the main branch (trunk).

  • Tag

Tagging is to mark particular revisions (e.g. release version), so that you can recreate a certain build or environment at any time. Tags are used to create a static snapshot of the project at a particular stage. Tagging of the project is mostly done along with the successful build and generally it is done by the automated build process.

Important Note: Subversion itself makes no distinction between tags and branches, but they are there for different purpose. Tags are not normally used for development, Branches must be used for that purpose. So working on a tag revision is not a good idea. So you must remember this as there is nothing to stop you doing this by mistake. However there are few SVN-Client Applications (like TortoiseSVN) which will warn you if you try to commit to a path in the repository which contains /tags/. But I am not sure about other SVN-Clients.

Figure 1: Example of a Subversion Repository Structure (expanded).

Branching or Tagging done by Subversion are just internal links (cheap copies) pointing to a specific tree/revision and thus can be created very quickly and also take up almost no extra space in the repository. If you modify a working copy created from a branch and commit , then all changes go to the new branch and not to the trunk. Only the modifications are stored and the rest remains a cheap copy.

Many times it may happen that you need to make further changes to a release which has been already tagged. The correct way to handle this is to create a new branch from the tag first and commit the branch. Make Changes on this branch and tag the branch for every build with increment in the Revision number.

So finally "What should be the ideal Repository Structure"

Following folder/directories must be created, all at the repository root level:

      • /trunk                    
      • /branches                    
      • /tags                    

How to make the Repository Structure:

  1. Do SVN Checkout to a new folder.
  2. Create the folder /trunk inside the root repository folder.
  3. Create the folder /branches inside the root repository folder.
  4. Create the folder /tags inside the root repository folder.
  5. Copy the project files (which are to be Source Controlled) in the /trunk folder.
  6. Add the files and folder to SVN and do SVN Commit.
  7. Create a Branch with Major and Minor mentioned in the branch name for e.g. "v1_0_X" **
  8. Now you can delete the new folder from your machine (not from SVN) as it is now saved in SVN.
  9. Checkout the newly created branch. Now you can start working on this.

If you need to make further changes to a release which has been already tagged, following steps must be followed:

  1. Checkout the tagged revision to a new folder.
  2. Create a new Branch from the checkedout project.
  3. Switch the working copy to new Branch (or in simple words Delete the just created new folder and checkout the new branch to a new folder.)

For e.g.  Suppose you need to make further changes to a release tagged "v1_0_60924_0". Steps will be as under:

  • Checkout the tag "v1_0_60924_0" to a new folder say "C:\HelloWorld_temp".
  • Create a new branch "v1_0_60924_X" *** by giving the command from within the above folder.
  • Switch the working copy:
    • Deleting the "C:\HelloWorld_temp" folder.
    • Checkout the branch "v1_0_60924_0" to a folder "C:\Projects\HelloWorld".

** Branch name v1_0_X dissected: "v" represents the word "Version", "1" is Major, "0" is Minor and "X" is to indicate that along with the changes (or during the Build process) Tags will be created with dynamic Build and Revision numbers, for e.g. "v1_0_60923_0" here 60923 is the Build Number which represents the date of build (6 is the year 2006, 09 is the Month and 23 is the Date), after Build Number there comes the Revision Number which will get incremented with every next build during the day.

*** In case of already tagged release Branch name used is "v1_0_60924_X" because for further builds on this Branch only revision number will get incremented. Mostly this happens when a Build is released or finalized to be released, then for bug-fixes and patches to be release the Build number is freezed and only Revision number changes.

posted on Monday, September 25, 2006 8:23 AM

Feedback

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 1/20/2008 1:43 PM steve
> Build: This is auto-generated number, assigned for each build on a day basis. It has YMMDD format, So Feb 04th 2006 shall be 60204.

So what will the build number be on Feb 04th 2016 s

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 1/21/2008 3:12 AM Cuong Huy To
Hello, thanks for the guide,

Also like Steve, I wonder how the "Build" number is automated. I thought that it is a manual work: we type in as the build-number the date we commit to that branch.

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 5/13/2008 7:06 PM Manish Agrawal
Hi Steve & Cuong,

Few Clarifications for the above mentioned version number format are as under:
1. I have used the Microsoft standard for generation of Build No., i.e. if you see versioning scheme in .Net Framework & other MS products it is the same.

2. Yes in case you are giving Build Numbers manually it will work fine. Since .Net generates the Version no.s automatically and also updates the Build No., I have written automatically above.

3. More over YMMDD is just written there to avoid 0 (zero) as starting digit, for 2016 it will automatically become 160204*.

* As of now there is an issue in this Microsoft has not taken variable type big enough to support values bigger than 65000 i.e. this scheme has failed in year 2007 itself.
Once Microsoft fixes this bug this issue will be over and things will work well.

Thanks for your comments...

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 6/4/2008 8:19 AM Brien Malone
Thank you. This was very helpful... I'm new to subversion and was googling "best practices". Most people pointed back to the documentation, which, as you said, is a lot to take in one go. Thanks for breaking this part out and making it easy to understand.

# this part could be clearer 4/1/2009 6:24 PM xyzzy
From the article:

" How to make the Repository Structure:

1. Do SVN Checkout to a new folder.
2. Create the folder /trunk inside the root repository folder.
...
"

There's a bit of chicken and egg here.

step 1: do svn checkout to new folder implies an existing repository

step 2-4, create folders trunk, etc "inside the root repository folder" is a bit of context shift

does the author mean, create these on the filesystem underneath the 'new directory' from step 1?

or create them in the repository, with svn commands?

or just create them in the filesystem, in the repository directory? (assuming fsfs)




# date /= build number 8/25/2009 8:34 PM Knowname
Don't confuse dates and build numbers! Don't use one for the other… use an integer for the build number, when you do a build increment the number whether the build is successful or not, when its done tag it with the build number. If you care to know when the build was performed, it will be in the log. Using dates in place of build numbers is a rookie mistake.

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 6/19/2010 1:41 PM pt
Why bother with all the headache of tags? IMHO, tags and complex version labeling schemes are architectural cruft left over from the days of CVS and PVCS. Systems like Subversion and Perforce have an atomic change number which is easier to use. The file revision associated with a change number can never change. Conversely, the file revisions associated with a tag can change. This means a tag is not a solid stake-in-the-ground, it's more like a soccer ball that can be kicked around by anyone. If you're depending on it being over specific blades of grass, you might get lucky and you might not.


# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 8/4/2010 7:01 AM Alvin Schatte
It looks like you propose the root/<trunk,branches,tags>/project organization. What do you think about a root/project/<trunk,branches,tags> organization?

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 8/4/2010 7:08 AM Manish Agrawal
Actually that is right... it is always root/project/<trunk,branches,tags>

Thanks for pointing it out Alvin...

for pt's comment... tags are convenient names to Revision numbers... there is no hard and fast rule... but only how you want to organize your things...

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 8/4/2010 10:37 PM glyza
hi.. I'm doing a research about subversion. I'm still confused in the folders trunk, branches and tags. I don't really understand the difference between the three..

# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 8/20/2010 5:00 AM Bakopanos Costas
a simple tortoise explanation on subversion structure...

http://www.deaddevssociety.com/2010/08/create-subversion-repository.html


# re: How to use Subversion more effectively with proper Repository Structure and better use of Branching/Tagging/Versioning.. 11/8/2011 2:55 AM Rangalal Gamage
thanks for the guide

Post A Comment
Title:
Name:
Email:
Comment:
Verification: