Hook Implementation in Subversion

Lets Disucuss best way to implement Hook with SVN?

This is very useful content to know aboutr hook in SVN


pre-commit hook, what is the best way of implementing using ActiveDirectory accounts, and the right way to test it before implementing it in real?

Tagged : / / / /

Next Generation Software Configuration Management with Subversion

Next Generation Software Configuration Management with Subversion

Next Generation Software Configuration Management with Subversion

Tagged : / / /

SVN (Subversion) Branching Strategy

Version control systems play a vital role in the success of a software development team. This blog aims to provide a simple branching and merging strategy to manage the code in a fast paced team development environment.

When do you need branching?

You may need to adopt branching in many different scenarios. Let us assume that on a day to day basis you use agile methodologies such as extreme programming or scrum and you have finally released a reasonably complex project with Version Couple of days after the release, you get a request for a new feature that must go as Version You envision it will take couple of weeks to get that feature coded, tested and released. Meanwhile, simple modifications and patches are requested on a day to day basis in the Version

Essentially, with the changing business needs you are required to do a deployment every other day or so i.e. your deployment cycle is 2 days or less.

With a team of 10 developers it will be a nightmare in the absence of a proper branching strategy.

Trunk, branch, and tag are the 3 main divisions in subversion repository.

The code in trunk is always maintained as close to release state as possible. Any developer making changes to the trunk must be absolutely certain that his or her part can be coded, tested and is ready to deploy within 2 days (can vary depending on your length of deployment cycle). If it takes more than 2 days, they are not allowed to directly change the code in the trunk. They have to create a branch.

Developer Branch:
Each developer must create his or her own branch if their code will take more time to program than your normal deployment cycle. It is the responsibility of the developer to regularly (timeframe depends on your development environment) merge changes from trunk to his branch.

Feature branch:
Create a feature branch if 2 or more developers are going to work on a new feature that will take considerable time to complete. It is the responsibility of the team lead to merge changes from trunk to this feature branch on a regular basis.

It is always beneficial to merge changes from trunk frequently. Because, after a couple of days conflict between trunk version and branch version can get out of hand and merging will practically be impossible.

When the developer branch or feature branch is ready for release, merge changes back from the branch to trunk.

Tag is similar to branch. When you create a branch simply rename the folder from branch/branches to tag. I always use Tags to tag a release whenever a new release version is deployed. This will come in handy if a very minor patch has to be made on the release version when your trunk is temporarily dirty. Ideally, you do not merge from trunk to the tag.

Finally, remember that there is no ideal branching and merging strategy. It pretty much depends on your unique development environment. If you have any other strategy, I would like to hear about that.

It is an exciting time for Subversion as its adoption continues at a dizzying pace in enterprises. I’m out there helping that adoption so I’m a bit late in posting the questions and answers I promised around the three basic branching strategies that I covered in the last two webinars in which I presented (Branching and Merging Strategies for Subversion 1.5 and Advanced Merge Tracking and Branching with Subversion 1.5). Hopefully these will be useful to many of you.

First, a quick reminder on what the three branching strategies were:

1. The unstable trunk which mimics the way that Subversion itself is developed. In this model, development is done on the trunk and a release branch is created around the time of feature completion with the formal promotion process carried out on that branch.



2. The stable trunk where development is done on system version branches and the promotion process is also conducted on that branch. The trunk is the branch point where the production releases are merged in and parallel development efforts are branched out.


3. The agile release strategy where development is done on individual feature branches and a release branch is created late in the process with the feature branches merged to it that will define that release. The formal promotion process is conducted on the release branch and the production version merged to the trunk as well as to all remaining active feature branches.

So on to the questions, first general branching questions:


Does the number of branches affect performance of the Subversion server?

No, branches are not just cheap in space and fast to create, they are alo just additional paths not unlike directories in the directory structure of your project. Of course, every tool has scalability issues at some point and Subversion logically has its limits, but in practical use, a scalability issue for Subversion around branches has not yet been experienced.

Can we use multiple strategies on one project?

Absolutely, there are many times when you may find a need to mix at least two branching models on the same project. For example, Internet applications may have very frequent releases focused primarily to address defects along with longer term release efforts to address broader feature development. The frequent releases may follow the unstable branch approach where they are worked primarily on the trunk and are branched, sometimes weekly or even more frequently, to do the formal QA to get to the release. The longer running enhancement releases may use the stable trunk philosophy though obviously the trunk isn’t actually stable, but the rest of the strategy is followed.

What strategy is best for a repository with multiple projects?

There is no need to have a single strategy in such a case. Instead one should use the appropriate method for each of the projects. Since each project should have its own top level directory for its branching model, there is no reason to force a particular method on all projects.

How does continuous integration affect branching strategies?

I’d hope that this isn’t the deciding factor in determining an appropriate branching strategy, but certainly the feasibility of continuous integration is impacted by the strategy chosen. With the unstable branch, continuous integration would be focused on the trunk and thus is stable as well as very useful as it identifies issues in the daily development commits. This is still relatively true when you look at the stable branch strategy where there may be multiple system version branches under development at the same time, but each is the focus of the majority of the development commits. The agile release model is the least accessible for this approach because of the number of active branches to try and monitor. That doesn’t mean continuous integration can’t be used but just that it is more difficult to implement and maintain.

Unstable Trunk questions:

Can this model handle parallel development if it only happens occasionally?

Any model can be morphed to handle exceptional situations, but this isn’t recommended. It is important to use a strategy consistently so that everyone understands where to find things during development and historically. That said, we’ve already talked about the potential of using multiple strategies on the same project so that’s certainly a possibility where the parallel development need could be addressed like with the stable trunk strategy.

Do I ever recommend merging from the trunk to the branch?

Never say never, but the situation would be pretty rare. I could potentially envision where a nearly complete bug fix or even an enhancement of importance is completed quickly enough on the trunk that there could be a compelling reason to merge it into the unreleased, but branched version.

How would you handle branches for customers that will have ongoing customizations for individual customers in this model?

Branches for this purpose can really be applied to any of the three basic branches we’ve discussed. The concept is that the base product continues to evolve and the branching strategy addresses that evolution. As production releases are made, the new revisions are merged to the customer-specific branches which contain customizations for that customer. There is also the potential of customer customizations being merged into the base product. The customer branches support the unique nature of customer specific changes while allowing for an upgrade path and the potential of contributing back to the base product.

Stable Trunk questions:

Version 1.0.1 didn’t get merged back into the trunk, shouldn’t it have been merged back?

Possibly, but I actually didn’t do so on purpose. With all the models, there is the potential that multiple releases are deployed in production and thus need to be supported. Therefore, there is the potential that bug fix releases are being made for multiple releases and merging all of them back to the trunk could mean intertwined versus serial releases. I therefore usually suggest that the actual production releases may be the only ones merged. Obviously, in my diagram that situation didn’t occur so it is a fair question.

There is a merge to the trunk outside of a release point, doesn’t that violate the stable trunk idea?

Yes, that can violate the stable trunk concept, but stability isn’t necessarily limited to just production releases. In this case, the purpose is to have a more up-to-date starting point for the system version branch. How strict you implement the idea of stability is up to you.

Should the development team develop the first version in the trunk or in a release branch?

Since my base principle is keeping it simple, I tend to say do the development on the trunk since there is no reason for creating a branch. The assumption is that parallel development won’t happen until the first release is made and other work won’t be merged until the release. This isn’t being pure to the strategy, but true to the base principle.

Agile Release questions:

In this strategy, is there any attempt to keep the task branches in sync with each other?

No, there really isn’t any way to define how you would keep isolated tasks in sync since there is no idea what will be released together until we get to the definition of the release branch. There is a need to keep the branches sync’d with production releases, but no way to do more.

Is there any reason that an Internet application should NOT be using the agile release method?

Sure, there are still many such applications that are released in a waterfall manner and are unquestionably successful. For example, release agility may not be required if releases are being made frequently enough. Keep in mind that there is more to keep in sync in this model which has to be balanced against any benefits.

Where is the release package built from?

I think the package would be built from the release branch since that’s logically where the promotion model process is conducted, but it can certainly be argued that the testing can be done on the release branch and then the approved revision merged to be tagged from the trunk. My absolute expectation is that you be consistent where you do build and tag.

How can a CM manager make sure all task branches were merged to the release branch?

Today, I would suggest the use of svnmerge.py where merge tracking is recorded in a property for all branch merges. Obviously, this will be easier with 1.5 where the log command can expose this information. Another approach would come from integrating issue management with Subversion where the merges would be reflected in the record for the release.

I’m sure I’ll return to answer some more questions around these branching models and merge tracking before long. Right now, I’m off to help another enterprise successfully implement Subversion.









Tagged : / / / /

Apache Subversion 1.7 has Arrived | What’s new in Subversion 1.7 ?


Apache Subversion 1.7 has Arrived

Subversion 1.7.0 has been officially released today.  With the release of Subversion 1.7 comes the release of Subversion Edge 2.1.0.  This release of Subversion Edge brings you the server binaries for Subversion 1.7.0 as well as the latest release of Apache httpd.  In addition to the inclusion of the Subversion 1.7 server binaries this release of Subversion Edge brings a number of other nice improvements including the addition of a complete 64-bit Windows binary stack.  As with all previous Subversion Edge releases you can simply update your existing installation from the Subversion Edge web console.  There are no other special considerations, the update mechanism handles all details.

I encourage all users to update their Subversion Edge servers to this release so that you and your users can enjoy the new features brought from this release as well as the improved performance and fixes that comes with Subversion 1.7.  Look for updates to your favorite Subversion clients to follow shortly.

Source: http://blogs.collab.net/subversion/2011/10/subversion-1-7-0-released/

Tagged : / / / / / / / / / / / / / / / /

How to Examin History in Subversion (SVN)?


Examining History in Subversion

Your Subversion repository is like a time machine. It keeps a record of every change ever committed and allows you to explore this history by examining previous versions of files and directories as well as the metadata that accompanies them.

Several commands can provide you with historical data from the repository:

svn log
Shows you broad information: log messages with date and author information attached to revisions and which paths changed in each revision
svn diff
Shows line-level details of a particular change
svn cat
Retrieves a file as it existed in a particular revision number and displays it on your screen
svn list
Displays the files in a directory for any given revision
Tagged : / / / / / / / / / / / /

Basic Work Cycle in Subversion (SVN) – Overview


Basic Work Cycle in Subversion (SVN)

Subversion has numerous features, options, bells, and whistles, but on a day-to-day basis, odds are that you will use only a few of them. In this artile, we’ll run through the most common things that you might find yourself doing with Subversion in the course of a day’s work.

The typical work cycle looks like this:

  1. Update your working copy.
    • svn update
  2. Make changes.
    • svn add
    • svn delete
    • svn copy
    • svn move
  3. Examine your changes.
    • svn status
    • svn diff
  4. Possibly undo some changes.
    • svn revert
  5. Resolve conflicts (merge others’ changes).
    • svn update
    • svn resolve
  6. Commit your changes.
    • svn commit
Tagged : / / / / / / / / / / / / / /

Subversion’s Components – SVN Components Overview


Subversion’s Components

Subversion, once installed, has a number of different pieces. The following is a quick overview of what you get. Don’t be alarmed if the brief descriptions leave you scratching your head—plenty more pages in this book are devoted to alleviating that confusion.

The command-line client program
A program for reporting the state (in terms of revisions of the items present) of a working copy
A tool for directly inspecting a Subversion repository
A tool for creating, tweaking, or repairing a Subversion repository
A plug-in module for the Apache HTTP Server, used to make your repository available to others over a network
A custom standalone server program, runnable as a daemon process or invokable by SSH; another way to make your repository available to others over a network.
A program for filtering Subversion repository dump streams
A program for incrementally mirroring one repository to another over a network
Tagged : / / / / / / / / / / / / / /

| SVN | Subversion | SVN pros and Cons| SVN Repository Planning | SVN Repository layout


| SVN | Subversion | SVN pros and Cons| SVN Repository Planning | SVN Repository layout |

Subversion (SVN) Repository Layout

Single Project – One project per repository location


· Isolated revision numbers

· Isolated codebase

· Isolated security model


· Isolated codebase

· Multiple Urls to remember

· Multiple locations to maintain

Multi-Project Layout – Several projects in one repository


· Easy to merge code between projects

· Single url for all projects

· One repository to maintain


· Revision numbers span across all projects

· Harder to isolate users to appropriate repositories

Tagged : / / / / / / / / /

How to install subversion on Linux?


To install svn in linux and make it fully working , I found it really tough and it has taken my lots of time. I am thankful to Sanjay, who helped me in this and without him it won’t be possible.While installing this you will miss a small thing and you got stuck.But this is not at all tough like open source it’s really very easy.

Why I have choosed this topic to write is that, those who are using it first time will need some time to get full of subversion.

Now the latest version of svn is 1.6.9.

To install svn first you need svn tar file. Which can be downloaded easily from here or you can run these commands (depending on your required version).

wget http://subversion.tigris.org/downloads/subversion-1.6.9.tar.gz

wget http://subversion.tigris.org/downloads/subversion_deps-1.6.9.tar.gz (It contains the library required by svn)

This you can download any where, Here I am creating a folder svn inside /usr/local directory.(/usr/local/softwares/svn/).(So it will be easy for me to specify paths and you to understand).

To start the installation process first untar this two file.

tar -xvzf subversion-1.6.9.tar.gz

tar -xvzf subversion_deps-1.6.9.tar.gz (After untar you won’t find any particular folder named subversion_deps-1.6.9. Don’t worry for that it is keeping all the libraries files inside subversion-1.6.9)

Now have to configure it, but before that we have to check whether our system is having all the dependies or not, like APR(Apache Portable Runtime) and APR utility.

If it’s not there then we can get it from here,



once downloaded you can start configuring it.

tar -xvzf apr-1.2.12.tar.gz

cd apr-1.2.12




The apr util directory requires apr directory, so we need to specify path for that.

tar -xvzf apr-util-1.2.12.tar.gz

cd apr-util-1.2.12

./buildconf –with-apr=/path to apr directory (/usr/local/sofwares/svn/apr-1.2.12)

./configure –with-apr=/path to apr directory (/usr/local/sofwares/svn/apr-1.2.12)


The other directories we have to check before installation are,

autoconf 2.50 or newer (autoconf –version)

libtool 1.4 or newer (this you can find inside subversion-1.6.9 folder)

Neon Library 0.25.x or 0.26.x (inside subversion-1.6.9 folder)

Berkely DataBase (If it’s not there you have to install it.)

Download the file, db-4.6.21.tar.gz .

Apache web server greater then 2.0.49 (httpd -version)

zlib (inside subversion-1.6.9 folder)

After checking all this, we can start installation process,

cd subversion-1.6.9


./configure –with-berkelay-db=/usr/local/softwares/svn/db-4.6.21 (path of berkelay data base)


make install

Once we have finished that we need to map svn with apache.

Before that we have to check whether mod_dav_svn and mod_authz_svn modules are present or not,if not then install it.

yum install mod_dav_svn

and add this in /etc/httpd/conf/httpd.conf file

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

Make sure you will add these lines after LoadModule dav_module modules/mod_dav.so.

Now create one repository with svnadmin command.Run this command inside your subversion folder.

svnadmin create repos

after that you can check with,

ls repos

conf dav db format hooks locks README.txt

This full path you have to specify in SVNPath.

Then at the end of the httpd.conf file you have to add

#for svn path

DAV svn

SVNPath /usr/local/softwares/svn/subversion-1.6.9/repos

now restart ur apache.

For security purpose to give authentication to the user we have to create authentication file with the command,

htpasswd -cm /etc/svn-auth-file user_name (test)

New password : test123

Re-Type passwd : test123

And to specify which access you want to give the user, create svn-access-file inside /etc.

Inside this file add code as,


* = rw

This will give authentication to every user specified in Require user inside location.

You can specify this inside httpd.conf file as,

DAV svn

SVNPath /usr/local/softwares/svn/subversion-1.6.9/repos

AuthzSVNAccessFile /etc/svn-access-file

AuthType Basic

AuthName “Subversion repository”

AuthUserFile /etc/svn-auth-file

Require user user_name


Now you are ready to import files in the repository, with the following command.

svn import -m “Initial import.” path(from where you want to import file) file:///usr/local/softwares/svn/subversion-1.6.9/repos/(repository path)

after running this command don’t worry it is not goin to display any thing inside repos folder. To check that you can run it in the browser.

http://localhost(you have to give your domain name)/svn/repos

Now you are ready to checkout the files with any svn client. For linux user smartsvn is best.

After doin this you can start ur smartsvn client and can follow these steps,

check out project from repository -> manage -> add -> enter svn url

enter ur url here http://localhost/svn/repos

enter ->ok

server name and repository path it will take automatically. click next, choose user radio button and give user name and password.

follow the steps to fetch the files.


To install smartsvn, first get the smartsvn tar file.

untar the file, with the command

tar -xvzf smartsvn-version.gz

for smartsvn first check the correct version of java is available or not, with

java -version command.If it is coming like this then you can proceed.

java version “1.5.0_14?

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)

Java HotSpot(TM) Server VM (build 1.5.0_14-b03, mixed mode)

Sometimes java will be installed but not the JRE. In that case simply re-install java.

Can install the latest version of java with rpm bin file.



go through the license and say yes.

It will installed in /usr/java/

Now have to make chnages in .bash_profile file.

cd /root

vi .bash_profile

give JAVA_HOME path.

JAVA_HOME = /usr/java/jdk1.5.0_14

Then compile it with the command,

source .bash_profile

then again check with java version.

Now you are ready to utilise the full feature of subversion

Tagged : / / / / / / / / / / / / / /

Work on remote Subversion repositories locally with Git


Work on remote Subversion repositories locally with Git

Version control is great stuff, and being able to combine different version control mechanisms is even better. Subversion is a very popular version control system and a lot of repositories (public or otherwise) use Subversion to manage files. Git is another popular one, but what happens if you are working on a project where Subversion is used but Git is your preferred version control system?

With the git-svn plugin, you can have the best of both worlds. You can convert a Subversion repository to Git, use Git tools, then push the changes back to Subversion.

To begin, you will need the git-svn plugin installed. Most likely, if your distribution of choice provides Git, it will also provide git-svn. On Fedora, install it using:

# yum install git-svn

Then use git-svn to check out your Subversion repository into Git format:

% mkdir -p ~/git/code

$ cd ~/git/code

% git svn init http://svn.host.com/svn/code

Initialized empty Git repository in /home/user/git/code/.git/

% git svn fetch

This may take a while on large repositories

r267 = 079b7c1cff49187d1aabc4b16f316102088fdc0d (refs/remotes/git-svn)

W: +empty_dir: trunk

r268 = 3f1944530a092c811c55720bd9322b8c150a535b (refs/remotes/git-svn)

r351 = e2af3c12e5ed174d23ffc5917f03a6136f8ebb6b (refs/remotes/git-svn)

Checked out HEAD:

http://svn.host.com/svn/code r351

At this point, the Subversion repository located at http://svn.host.com/svn/code has now been checked out in Git format. On individual files and directories, you can use the git log command as you would the svn log command in order to get history information on the item in question. With git, you will also see the Subversion commit that corresponds to the log entry, for instance:

commit 23f705cd87e1e9c6dd841ca88a14d808e0c4292a

Author: user@HOST.COM

Date:   Sat Mar 20 18:25:38 2010 +0000

correct logic on the buildrequires extractor, add stats on BuildRequires to showdbstats output

git-svn-id: http://svn.host.com/svn/code@350 7a5473d1-2304-0410-9229-96f37a904fa4

With the above, you can see that user@HOST.COM did the commit, see the log message, and the Subversion revision (r350).

To work with these files, make changes as normal. git diff works like svn diff does, to see the changes made. To commit changes, use git commit like you would use svn:

% git commit -m “some minor change” file

[master 2454be1] some minor change

1 files changed, 2 insertions(+), 0 deletions(-)

To update your local copy from Subversion, instead of using svn update use git svn rebase. This will merge in any changes found in the Subversion repository.

When committing files using git commit, you are committing your changes to the Git repository. None of these changes are pushed to the Subversion repository until you specifically tell Git to do so. This is done with the git svn dcommit command, which then takes each commit made to Git and pushes them to Subversion as individual commits, which will retain all of your history and log comments:

% git svn dcommit

Committing to http://svn.host.com/svn/code …

M      trunk/rqp

Committed r352

M      trunk/rqp

r352 = 0557314a580c4390ff646380baa3aa33d1f6a5cd (refs/remotes/git-svn)

No changes between current HEAD and refs/remotes/git-svn

Resetting to the latest refs/remotes/git-svn

Unstaged changes after reset:

M      trunk/rqp

M      trunk/rqp

Committed r353

M      trunk/rqp

r353 = 249e97283ad28126bf84ccaffb32873e12d15b7b (refs/remotes/git-svn)

No changes between current HEAD and refs/remotes/git-svn

Resetting to the latest refs/remotes/git-svn

Now, if you were to look at the changed file(s) in Subversion (via another Subversion working copy or something like ViewVC), you will see the individual commits. Above, there were two changes made to the trunk/rqp file, each committed locally to Git. The “dcommit” command pushed those changes as individual commits to the Subversion repository. In this way you can do all local development with Git and when you have something you want to commit to the Subversion repository, you can push all of the relevant changes at once, retaining each separate commit.

Using the git-svn plugin makes it extremely easy to use Git locally with a remote Subversion repository. If you are in a project or organization that, for whatever reason, does not want to convert to Git, you can continue to work with that Subversion repository, without the restriction of using Subversion yourself.

Tagged : / / / / / / / / / / / / / / / / / / /