Sub-Subversion

In the corporate market

2009-05-15T00:37:00.000-07:00

Even if centralized version control vanishes from the open source
world, I have a feeling it will be around for a *long* time in the
world of corporate development. Subversion is just starting to get
competitive with big commerical systems like Perforce and Clearcase --
especially now that we've added merge-tracking features. This market
isn't about to go away any time soon.

Ben Collins-Sussman, 2007-06-28, Re: A word of thanks to the Subversion team

Although I'm not sure that Subversion will vanish from the Open Source world, how damn I agree with Mr Collins-Sussman. Subversion is ready for the corporate market and has a few real advantages over commercial product:

price
easy to understand (and this is a true winner). Although I don't know about Perforce, I can tell that ClearCase is not for dummies.
Platform support and integration
fast setup. Moving a dev team from nothing to subversion should take no longer than a week of work (excluding training).
nearly zero admin job.

I'm thinking of getting a new post on this blog, something called how to win with Subversion? so stay tuned.

Why you should use subversion 1.6: Relative URLs

2009-04-16T03:49:00.000-07:00

Introduction:
Now that Subversion 1.6.1 is out, improving and fixing a few things in Subversion 1.6, it is time for us to review some of the most important features provided by this new release. Because a few of the new features of Subversion 1.6 remain undocumented and because the latest version of the Subversion book does not yet cover Subversion 1.6, I do hope you might find helpful information in these reviews.

We will start today with the relative urls feature.

Relative urls and the svn:external property:
Subversion 1.5 introduces some relative URLs shortcuts available in the svn:external property. Because a server URL tends to change more often than the structure of a Subversion repository, in the svn:externals property, you no longer need to write the full URL to each source directory.
The syntax for each these shortcuts is:

'../'
URL of the parent directory on which the svn:externals property is set.
EG:
url: http://my.svn.domain.com/a/long/path/to/repo/and/to/my/property,
shortcut '../' points to http://my.svn.domain.com/a/long/path/to/repo/and/to/my
shortcut '../../' points to http://my.svn.domain.com/a/long/path/to/repo/and/to/
'^/'
URL of the root of the repository in which the svn:externals property is set.
EG:
given the same url,
shortcut '^/' points to http://my.svn.domain.com/a/long/path/to/repo
'/'
URL of the Server which hosts the repository in which the svn:externals property is set.
EG:
given the same URL,
shortcut '/' points to http://my.svn.domain.com
'//'
Relative to protocol of server URL
EG:
given the same URL,
shortcut '//' points to http://

Because it has already been covered, please refer to the Subversion book for more information about the relative url shortcuts in the svn:ex

Repository root relative urls from the command line:
Although the support for relative urls in the svn:externals property is already a nice addition, the subversion development team went one step further by providing the repository root relative urls feature with the command line client of Subversion 1.6.

The syntax for each these shortcuts is:

'^/'
URL of the root of the repository.
'/'
URL of the Server which hosts the repository
'//'
Relative to protocol of server URL

For example, creating a simple tag prior to 1.6 you write:

svn copy http://svn.domain.com/repo/trunk \
http://svn.domain.com/repo/tags/release-1.0 \
-m "Tagging for release 1.0"

Using the relative root URL in Subversion 1.6, it is much simpler:

svn copy ^/trunk ^/tags/release-1.0 -m "Tagging for release 1.0"

The repository root relative syntax is '^/', not '^'. So use '^/' to refer to the root of the repository. URLs that begin with a '^' are reserved for future extension. Also '../' is a shortcut only available in the svn:externals property definition. It is possible to use it with the command line client.

The benefits of the relative root URL feature are:

Type less
Less typo error in the URL
Ease automation
Easier to move your repository from host to anotherr.

How does the magic works, you ask?
The client start to look for any non relative URLs in the paramters list. If these non relative URLs are all identical, the client replace all relative URLs in the parameters list with the root URL of the non relative one. If they are no non relative URLs in the parameters list, the client uses repository root URL for the current working copy. If the current folder is not a current working copy, the client reports an error. The same goes in every other situations.

An example you ask?
The working copy is located in $WC. It currently is a checkout from the trunk of your project located in http://some.domain.com/svn/repo

svn copy http://some.domain.com/svn/repo/trunk ^/tags/release-1.0 -m "..."
http://some/domain.com/svn/repo/ is used to replace ^/
svn copy ^/trunk ^/tags/release-1.1 -m "..."
The above command fails provided it is started outside of a working copy
cd $WC ; svn copy ^/trunk ^/tags/release-1.1 -m "..."
http://some/domain.com/svn/repo/ is used to replace ^/
svn switch ^/tags/release-1.0
successfully switch your working copy to http://some.domain.com/svn/repo/tags/release-1.0

source: cli-repo-root-relative-support.txt

There is a war out there.

2009-04-15T03:08:00.000-07:00

I think we are at the golden age of free Version Control Software. Look at the few active examples below:

Bazaar: Distributed Version Control System sponsored by Canonical Ltd, part of the GNU project and written in Python. Bazaar supports working with or without a central server and has support for working with some other revision control systems like Subversion.
Available on all platform with Python 2.4 support.
CVS: Centralized Source Control system, CVS is the Successor of RCS and ancestor of Subversion. CVS development is stalled (only 2 bug fixes release in 2 years, no new feature).
Available on Unix like and Windows
darcs: Distributed Version Control System written in Haskell by David Roundy. DARCS is built around Roundy's theory of patch.
Available on Unix, Linux, BSD Mac OS X and Windows
DVCS: Distributed Version Control System by ElegoSoft. DVCS extends the programs CVS and CVSup with functionality to distribute CVS repositories with local lines of development and automatically handles the synchronization of the distributed repositories in the background.
Available on Unix, Linux, BSD, Mac OS X and Cygwin (Windows)
Fossil: Fossil is a distributed software version control system that includes an integrated distributed wiki and an integrated distributed bug-tracking system all in a single, easy-to-use, stand-alone executable. Fossil is one of the latest DVCS to date and is written by D. Richard Hipp, the same guy who wrote SQLite.
To the best of my knowledge, it is available on Linux, Mac OS X and Windows.
Git: Distributed Version Control System originally written by Linus Torvalds for the Linux Kernel development after a Bitkeeper license issue. Git was inspired by BitKeeper and Monotone with an emphasis and being fast.
Available on Unix, Linux, BSD, Mac OS X and Cygwin (Windows).
Mercurial: Distributed Version Control System written in Python and C, started at the same time and for the same reasons than Git. It is designed as a lightweight DVCS which efficiently handle very large distributed project.
Available on Unix, Linux, BSD, Mac OS X and Windows
Monotone: Distributed Version Control System written in portable C++ using peer-to-peer synchronization protocol, supporting fully disconnected operations. Each participant maintains their own revision history store in a local SQLite database. Like Fossil, Monotone is held in a single-file executable with a single-file SQLite database repository. Focus on integrity over performance.
Available on Unix, Linux, BSD, Mac OS X and Windows
OpenCVS: Version Control System developed by the OpenBSD Project which aims at staying as compatible as possible with GNU cvs while being as secure as possible and enhance the access control on repository files. OpenCVS is not yet available (AFAIK) but is actively developed by the same team behind OpenSSH.
Not (yet) available.
Subversion: is probably the most popular Version Control System. It is initiated in 2000 by CollabNet Inc and aims to be the successor of CVS, while fixing bugs and misfeatures of CVS.
Available on Unix, Linux, BSD, Mac OS X and Windows.

By the way, they all suck one way or another...

As in every war, you have casualties. Please observe one minute of silence remembering:

GNU Arch, from the GNU project
RCS, from the GNU project
SCCS, from Bell Labs
ArX, a fork of GNU Arch by Walter Landry
Baz, another fork of GNU Arch, ancestor of Bazaar by Canonical ltd
Codeville, from Ross Cohen
OpenCM, a VCS for the EROS project
FastCST, experimental tool written in ruby.
Supervision, by Stefan Reich

On the other hand, CVS is in the list because of its past fame and glory. Feel free to add more in the comments section.

Subversion hosted Issue tracker

2009-04-14T07:27:00.000-07:00

Gregoire Welraeds wrote:

>> I'm looking for subversion hosted bug tracker. That is why I
>> mentioned DITrack and subissue in my previous post. I have the feeling that this >> 2 projects are stalled.
> Why do you want to use a tool for something it doesn't do well?

For a few reasons, among others:

Change Requests/issues are tightly related to the code source. IMO, they could even be part of the code, like comments and documentation are. Change request could be stored directly in Subversion repository, next to the source.
It could enforce teams to work with an issues tracker. To some extend, Subversion commits comments are just an extension of a Change Request description.
Subversion is very good at manipulating text files and their modifications. Why should I use something else?
There should be no need to setup additional infrastructure for basic needs of issue tracking. Why should I be using a third party software for something which is part of my code, especially if it is bundled with a third party database.
It would let me work while being offline. Once online: svn update . / svn commit . to import my modifications to the issue tracker.
A tight integration of an issue tracker in subversion would let us benefits from the inherent features of the VCS and stronger the interaction between the two. For instance, I could branch my change requests tree while creating a feature branch in the code. I could easily filter the changes requests by branches, be it maintenance, development, feature branches without having to artificially created the same in an external third tool.

As a release manager with a team of 10 developers using Seapine TestTrack Pro*, I always end up to look at svn logs to document the release. These are only thoughts but I'm sure there are other advantages of having both VCS and Issue tracker integrated. BTW, the idea is not
mine: see subissue, DITrack or even Fossil scm.

* With subversion integration.
For the above mentioned projects see:
Subissue
DITrack
Fossil
Follow the remaining of this discussion on the Subversion users mailing list archives.

Rollback a change with a reverse merge (II)

2009-04-12T15:26:00.000-07:00

An common use for svn merge is to roll back a change that has already been committed. In August 2006, I wrote an article explaining how to manually rollback a change with a reverse merge. The solution described by that time was based on a inverted range of revision:

svn merge -r 481:480

With the release of Subversion 1.4.0 in September 2006 (no luck), a new -c paramater is added to the svn merge command:

-c [--change] ARG :the change made by revision ARG (like -r ARG-1:ARG).
If ARG is negative this is like -r ARG:ARG-1

Using -c -ARG is equivalent to using -r ARG:ARG-1 but is more user friendly:

svn merge -c -481

Do not forget to commit the modifications to your local copy after the merge:

svn commit .

source: basic merging, subversion changelog

First and foremost

2009-04-12T02:20:00.000-07:00

The very first entry in the Subversion change log (05 June 2000):

* CVS repository created.

(via twitter)

Upgrade to 1.5

2009-04-10T00:36:00.000-07:00

Subversion 1.6 is out, Subversion 1.4.x is no more supported. Time to upgrade my svn server from 1.4.2 to 1.5.6. The subversion server runs on a Debian GNU/Linux with a 2.6.8-2-386 kernel and apache 2.2.

The procedure is rather straightforward:

Upgrade all clients to 1.5.x. Older clients and servers interoperate transparently with 1.5 servers and clients. However, some of the new 1.5 features may not be available unless both client and server are the latest versio. So it is a good starting point.
Update the subversion tools. On Debian based system, it goes like:
$ apt-cache showpkg subversion
Package: subversion
Versions:
1.5.6dfsg-1 [...]
$ apt-get install subversion=1.5.6dfsg-1
[...]

Update the SVN apache library. There is no need to update apache itself. But upgrading this lib will also install the latest mod_dav_svn module for apache. Although it is not mandatory, it is highly recommended. On Debian based system, it goes like:
$ apt-cache showpkg libapache2-svn
Package: libapache2-svn
Versions:
1.5.6dfsg-1 [...]
$ apt-get install libapache2-svn=1.5.6dfsg-1
[...]
Restart apache (apache2ctl restart).
Make a simple test:
$ svn --version
svn, version 1.5.6 (r36142)
compiled Feb 26 2009, 02:56:32
[...]
$ svnadmin --version
svnadmin, version 1.5.6 (r36142)
compiled Feb 26 2009, 02:56:32
[...]
We are fine.
Add a start-commit hook script to avoid 1.4.x and lower clients to commit to the repository. The repository format has changed, meaning that 1.4 and older versions of Subversion tools that normally access a repository directly (e.g. svnserve, mod_dav_svn, svnadmin...) won't be able to read a repository created by Subversion 1.5 More on this in a future post.

Upgrade the repositories from the 1.4 structure to the 1.5 one. The repository format has changed between the two releases but, repositories are not upgraded automatically. From the subversion 1.5 release notes:
some of the new 1.5 features will not become available simply by upgrading your server: you will also have to upgrade your repositories.
. Again, it is straitforward:
$ svnadmin help upgrade
[...]Upgrade the repository located at REPOS_PATH to the latest supported
schema version.[...]
$svnadmin upgrade REPO_PATH
[...]
It is harmless and run in seconds.

Optional: dump and reload the repositories. I've run the following quick test on a repository full of word/pdf documents:
- du -sh REPO1 -> 402M.
- svnadmin dump REPO1 > REPO1.dump
- du -sh REPO1.dump -> 780M.
- svnadmin create REPO2.
- cat REPO1.dump | svnadmin load REPO2
- du -sh REPO2 ->388M
The same test on a 153M repository full of JAVA, C/C++ sources and a few binary files gave a resulting repository of 102M. Depending on the number of repositories, the size of them, you should consider the dump/load operation. Please note that dumping a repository is very fast but load it can take some time. Consequently, you should probably plan the move outside working hours and bring the repositories down during the operation.

You are done!

Subversion 1.6

2009-04-09T01:56:00.000-07:00

Since March 20, version 1.6.0 is the main stable release of Subversion.
Amongs the new features,

svn:externals on a file.
CTypes python bindings
Filesystem storage improvements to both FSFS and BDB backends
Many (many) improvements to the command line client.
Repository root relative URL support on most SVN commands

See the official announcement for more information. Please note that Subversion 1.4.x are no longer supported.
In the coming days, I'll try to blog about these new features. I need to upgrade our subversion repositories from 1.4 to 1.6. I'll also try to report here my findings regarding the upgrade.

Rollback a change with a reverse merge

2006-08-21T03:04:00.000-07:00

Problem: A modification is commited to the source tree at revision 481.
After investigations, it appears that the modification done is not correct and the source should actually be like it was in revision 480. How to rollback the changes to the previous revision?

One possible solution is to perform a reverse merge:

$ svn merge -r 481:480 .
-> At this stage, your working copy is like it was at revision 480.
$ svn commit -m "rollback merge to revision 480"
Committed at revision 482.

There might be other way to rollback, but this one is the easiest. The merge will leave your working copy with modified files that you just have to commit.

The situation is a bit different when you are not merging from the head revision to the problematic revision -1. See the following situation: a problematic change is introduced in the file foobar.txt at revision 481. A valid change is added in the file foobar.txt at revision 482. A rollback of the changes introduced at revision 481 will most probably leave your working copy with conflicted changes in the file foobar.txt.

sourcce: cheat sheets