BoootStrapToday Subversion Server to be upgraded to1.7 soon

It’s been over two months since the Subversion 1.7 release was announced, since than there have been two bug fix releases and the bug & error reporting on the mailing list has gone down, It seems like right time for BootStrapToday Subversion server to be upgraded to 1.7.

So what to expect from this upgrade

• Improved performance of Subversion over http  : performance of Subversion over http has been one of the major concerns of Subversion community since early releases, Subversion 1.7 hits this problem right on head by introducing httpv2, PROPFIND discovery turnarounds have been removed and reduced number of round trips for a request, also there is better caching with web proxies, this was one of the most awaited feature by Subversion community as a whole.

• SVNRDUMP: Subversion 1.7 adds a new tool to the client’s toolbox, svnrdump replicates the functionality of svnadmin dump and svnadmin load, but works on remote repositories, instead of needing administrator access to the source or target repository, this would allow users to migrate repositories with ease from other sources to BootStrapToday

• Subversion 1.7 has taken caching to next level, 1.7 servers will aggressively cache data in-process to maximize performance.svnserve introduces a new --memory-cache-size / -M command line parameter to override the default cache size. Same  can be configured in Apache server as mentioned below

          <IfModule mod_svn_module>
             SVNInMemoryCacheSize 10240
          </IfModule>
      

With 1.7 server you will still be able to use your Subversion 1.6 clients.  However, we recommend that you upgrade to a Subversion 1.7 clients, because many operations will be faster.

We will update you on upgrade plan soon, we are thinking to utilize christmas holidays to do it, let us know your thoughts on same.

Enhancement in BootStrapToday Release 2.0

Following are some of the new enhancements in this Release

1) GIT support has been added.

Every Project you create in BootStrapToday has its own repository. So now while creating a new Project you can choose between SVN and GIT.

2) Login Page redesigned.

We felt the need to redesign the login page as per the design of the application, so we have pushed that as well in this release.

3) Ticket delete

Ticket delete feature has been added. This action will be available only to Project Manager.

4) Quick Ticket Edit

We had added “Quick Create” in the last release and in this we have also added “Quick Edit” functionality. This will be available in both Ticket list view as well as Milestone detail view. Now user can quickly edit multiple tickets from the same view without going through the different screens.

How to backup your project on BootStrapToday ?

Last week there was major outage of Amazon services.  We use Rackspace for hosting BootStrapToday and hence BootStrapToday was not affected. While Rackspace is renowned for its reliability and fanatical support,  every company who is using cloud servers for hosting is vulnerable to these kind of outages.  Today almost all major websites and services are hosted on cloud servers (either from Amazon, Google, Rackspace or someone else). All hosting companies and service providers like BootStrapToday make every attempt to ensure that backups are available and services are restored quickly, still it is important that you should a have a backup of your project data.

Obviously some customers asked us, what is the best way to take a backup of project on the BootStrapToday ?.  Some website have a way of downloading your data as single big zipped XML file or a database dump etc. While these solutions are good for one time backup, they are not really good for ‘incremental’ daily backup. On some website, you have to backup bugbase separately and source code, wiki etc separately. This is time consuming and error prone.

BootStrapToday took a different approach. All your projects data (i.e. source code, wiki pages, tickets, attachments, milestones and components etc) are stored in the projects subversion repository.  So once you backup Subversion repository of your project, you have  entire backup. Next question obviously how do I take backup of the Subversion repository ?

Answer is a little known Subversion utility called ‘svnsync‘.  Svnsync is the Subversion remote repository mirroring tool. It allows you to replay the revisions of one repository into another one, creating a mirror or backup copy of the repository.  Given below are steps to use ‘svnsync’ and create a backup of your project repository.

1. To use ‘svnsync’ you need a command line version of Subversion. If you are using unix/linux, chances are you already have the command line version. If not you can get/download the command line version of Subversion from
   • For Debian or Ubuntu : run ‘apt-get install subversion’
   • Apache Subversion Binary Packages
2. Create a new local svn repository on your computer where PATH is filesystem path of the local repository.
   
   • svnadmin create PATH
3. On Linux/Unix, create an empty ‘pre revision property change’ hook script.
   • touch PATH/hooks/pre-revprop-change
   • Make the script executable: chmod +x PATH/hooks/pre-revprop-change

   On Windows :

   • Create a batch file ‘PATH/hooks/pre-revprop-change.bat’
   • edit batch file and just add ‘exit 0’ (exit zero)
4. Now initialize the local repository for ‘mirroring or backup’. URL_TO_REMOTE_BOOTSTRAPTODAY_REPO is the
   repository root url that you use for ‘checkout’. You can get this repository URL from your BootStrapToday project dashboard.
• svnsync init file:///PATH URL_TO_REMOTE_BOOTSTRAPTODAY_REPO
  This command will prompt you for the username, password. It will set several revision properties on the to revision zero for later use. At this point it doesn’t actually copy any actual data.
  
5. Now you are ready to create a complete mirror of your project repository at URL_TO_REMOTE_BOOTSTRAPTODAY_REPO.
   
   • svnsync –non-interactive  sync file:///PATH
     If everything is correct then it will start copying the data from your bootstraptoday project repository to local mirror repository on your computer
   • Depending on size of your repository this step may take some time.

Now everyday you just have to execute step 5. Yesterday’s changes in the project repository on BootStrapToday will get copied to your local repository backup.  Best way is to add Step 5 as ‘scheduled task’ on windows or a cron job on Linux.

Campaign on SVN Vs GIT Usage

BootStrapToday currently supports Subversion as a version control for code and document versioning. As per data Subversion still commands 36% of the market share, which is by far greater than any other Version control software.  So we had assumed most of our customers will also fall in this category.

But recently there were some request from our customers and prospects for supporting GIT as well. We ran a small campaign with our existing customers and on linkedin before integrating GIT with BootStrapToday. We were aware about the trend of migration to distributed version control from centralized one, but to our surprise, results were astonishing. Please find the result of the campaign in the chart below.

This clearly states that people are more inclined towards GIT. So our initial assumptions were proved wrong.

So finally we will be supporting GIT in the April, 2011 end release. Thanks for your patience and support.

What Subversion 1.7 has in Store for You ?

It’s been a while I have been hearing about Subversion 1.7, which is finally expected to be released in Q1 of 2011 as per roadmap available here, it’s expected to be one of the biggest release in the history of Subversion.

So what to expect from Subversion 1.7?

In this post I am going to talk about some of the key features and enhancement which I have been waiting for, which is going to make my argument stronger on why you should use Subversion.

• WC-NG : It is the rewrite of working copy library,the .svn directories will be eliminated and there will be one big .svn directory in Working Copy root. Today Subversion takes something between 10 sec to 2 minutes to start after you enter svn command (svn info, svn up, etc…) that occurs because each .svn metadata directory will be read from the local disk first. That will no longer be the case, after WC-NG is introduced.

• HTTPV2 : Increases performance of Subversion over http, this is going to remove PROPFIND discovery turnarounds and reduced number of round trips for a request, this also going to include better caching with web proxies.

• SVN Patch: Subversion 1.7 features a new subcommand called svn patch which can apply patch files in unidiff format (as produced by svn diff and other diff tools) to a working copy.

• SVNRDUMP:Subversion 1.7 adds a new tool to the client’s toolbox: svnrdump. svnrdump replicates the functionality of svnadmin dump and svnadmin load, but works on remote repositories, instead of needing administrator access to the source or target repository.

• Server performance tuning: Subversion already support various caching mechanism like memcached, Subversion 1.7 is set to take caching to next level, 1.7 servers will aggressively cache data in-process to maximize performance.svnserve introduces a new --memory-cache-size / -M command line parameter to override the default cache size. Same  can be configured in Apache server as mentioned below

          <IfModule mod_svn_module>
             SVNInMemoryCacheSize 10240
          </IfModule>

      

GIT vs Subversion

There has been a lot of fuss about which is the better version control system among the likes of CVS, Subversion, Git, SVK, Perforce, Accurev, the list goes on and on. But I am going to limit myself to Git and Subversion which are frequently being compared in the arena of SCM. These two version control systems fall in two different categories

• Distributed version control systems like Git and Code Co-Op
• Centralized version control systems like CVS and SVN

Distributed Version Control system

• In a distributed version control system every developer has his own private copy of the complete source code on his or her machine.
• They can put changes in their modules and can sync their changes with other developers.
• If by any means, access to the developer’s machine with whom you generally sync is not available, you have options to sync it with others. Also there is no bottleneck as you can sync with anyone in your project.
• This system is generally structured as a pyramid, as developers at a particular level can deliver changes with other developers on their level or the level above them and at the top of the pyramid is the person who holds the decision of what actually goes in the main line of development.
• Developers can work on the source code their own way without affecting anyone else. These developers can work with their fellow developers and sync changes with each other.
• Each can decide what changes to accept or reject from their fellow developers.
• The advantage is that the code is distributed and there is no “point of failure”.
• Distributed systems enable a lot of private work in a way that is bad for the development.
• Maintenance tends to be sloppier on distributed systems.
• Git falls in this category; this type of development is not used very commonly. Perhaps the biggest example of this is Linux kernel development.

Centralized Version Control system

• In a centralized system there is a repository on the central server where all the source code goes.
• Every developer checks out the working copy of the same piece of code and then makes changes in their working copy and everyone can commit changes to the main line of development.
• Anybody can put changes in anyone’s module if no folder level control is exercised.
• In such a system every one gets the changes of other developers whether they are willing to do so or not. A centralized system is much more likely to be backed up and its hardware kept up to date.
• Subversion falls in this category. This type of development is very common. Sourceforge.net follows this type of version control.

The distributed systems do work by not needing a server (except for rsync and any web server). But truly speaking the server-less system they set up is more complicated in actual practice than a single well-maintained server.

The official claim is that a centralized server cannot handle distributed type of development. I disagree that centralized servers cannot handle this development methodology. Let’s imagine a centralized version control system that has excellent branch development capabilities. No developer directly works off the trunk. Instead, each developer has one branch that is created from the trunk. Developers can merge their branches into the trunk or in other branches as done in distributed systems. For this to work, branching and merging operations must be smooth. And even the pyramid structure of distributed system can be implemented by controlling which all branches are to be merged in the trunk.

Subversion can be better but this has nothing to do with centralization. With the benefits of a centralized system, Subversion also gives you the flexibility to be used as a distributed system if you use right approach to it.

This is my personal opinion based upon my experiences working in the software engineering field. Feel free to comment on it and point out errors in judgment, if any.