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.

Solving the build error Python.h: No such file or directory on Ubuntu

I was struggling due to this problem for couple of days and got the solution just now , I  thought to share it
with you all; as I don’t want anyone else to land up in trouble and waste so much time as I had to.

I use Hardy(Ubuntu) and was trying to build subvertpy  from source as the package was not available for same.

Why this error occurs

This problem occurs due to absence of Python development headers as many python modules have dependency on  Python development headers to compile.

Solution

Solutions are usually simple to such problems this one is no exception, just need to install development headers using package manager; open the terminal and issue the following commands

sudo apt-cache search python

and select the package that matches your installation as in my case it is python2.5-dev; issue the following command to install it

sudo apt-get install python2.5-dev

This will install development headers in /usr/include/python2.5 and now you can build your python module successfully.

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.

Mirroring Subversion Repository Using svnsync from BootStrapToday Account

Svnsync is a pretty handy and useful tool that comes along with Subversion installation for backup. At times taking backup of Subversion repository on file-system can get complicated as you need to ensure that files are not currently locked by any process. Svnsync can run on your live repository. You can have complete replica of your repository on your local machine without any major setup. Here I am going to discuss how you can use svnsync to backup your remote Subversion repository at BootStrapToday . Since BootStrapToday stores wiki, tickets and attachments in Subversion repository, you can get backup of all of your data.

This article assumes that you have created an account with BootStrapToday and have created at least one project. If you have not done it already you can create a new account from  BootStrapToday website signup page. You need to have Subversion installed on your local machine where you are going to mirror the repository.

Following are the steps required to perform the backup:

Step 1: Open terminal and fire following commad

svnadmin create /setup/repos/backuprepo

this will create Subversion repository at path /setup/repos/backuprepo, you can change path as per your requirment

Step 2: Edit the pre-revprop-change hook and add the following line

#!/bin/sh
exit 0

Step 3: Initialize the local repository

$ svnsync init --username USERNAME file:///path/to/localrepos https://<account>.bootstraptoday.com/source/<project>

Copied properties for revision 0.

Step 4: Run the first sync of repository

$ svnsync sync --username USERNAME file:///path/to/localrepos
 Committed revision 1.
 Copied properties for revision 1.
 Committed revision 2.
 Copied properties for revision 2.

[...]

Once you have done this, you can continuously run ‘svnsync sync’ command to periodically pull latest changes and keep your local mirror up-to-date.

Schedule Down Time for BootStrapToday

This is to inform all BootStrapToday users that BootStrapToday will be down for schedule maintenance and upgrade from 08th Aug 1000 hrs IST to 8th August 1500 hrs IST, we will update once the BootStrapToday is up and running again.

Thanks for your support & co-operation.

Update: BootStrapToday is up & running, we will soon update you with the enhancements made in this release.

BootStrapToday Now has Time Tracking Support

We are happy to announce that BootStrapToday has built in Time Tracking support now.

Salient features of time tracking are as follows

• Time logging for each ticket: Tracking of time on Task level could not be easier as BootStrapToday provides you with a timer on each ticket, just click on the timer and your time starts getting recorded and when you are done just click back on the timer, it stops the timer and duration between start and stop gets recorded as your time on that task


BootStrapToday Timer Ticket View

• Day view for logging time for complete day: Single place to log time on tickets from all projects, BootStrapToday has time sheet day view, you can add tickets to day view start or stop timer on day view and also edit the recorded time.
  

  BootStrapToday Timesheet Day View

• Week view for managing complete weeks time : Single place to manage time for the complete week.
  

  BootStrapToday Timesheet Week View

• CSV Export: Time can be exported in standard csv format
  

  BootStrapToday Timesheet Csv Export

Schedule Down Time for BootStrapToday

This is to inform all BootStrapToday users that BootStrapToday will be down for schedule maintenance and upgrade from 02nd May 1200 hrs IST to 2nd May 1700 hrs IST, we will update once the BootStrapToday is up and running again.

Thanks for your support & co-operation.

Update: BootStrapToday is up & running.