I’ll try to restart the version control blog with a new digest format.

Ben Collins-Sussman announced that Subversion makes transition under the wings of Apache Software Foundation. We also learn that Ben is Mercurial user now, at least for open-source projects :)

Jim Whitehead “Predicting bugs in code changes using SCM information” describes the experiment to try and predict bugs location, using historical information from SCM.

Our own SCM Comparison was updated to the recent master copy from Better SCM Initiative.

Full text of “Pro Git” book by Scott Chacon is available online: progit.org.

Why Git is better than X is a new DVCS comparison site.

An Illustrated Guide to Git on Windows.

(via Github blog)

http://use.perl.org/articles/08/12/22/0830205.shtml

More than twenty years of Perl development history has been migrated to Git and is available at http://perl5.git.perl.org/perl.git. Previously it used Perforce, and it was somewhat unfortunate choice for an open-source project.

via http://github.com/blog/276-perl-mirror-on-github

http://blog.joopp.com/2008/12/15/flickr-version-control/

This borders with unbelievable: how can textual conflict survive to Flickr homepage?

We’ve seen this pattern many times: you introduce version control to the team, and sooner or later someone encounters textual conflict. Less experienced users, such as HTML designers, copywriters, or even developers who are new to version control, tend to experience negative feelings, aimed towards Subversion and to you, by transitivity.

You carefully explain that all this time intelligent merging algorithm worked seamlessly, actually saving their time; that this is actual conflict between their changes and their colleague’s change. You track down that other person, and connect them both to work it out between them. They seem to agree, but I personally don’t have any illusion about what they think: that horrible “Subversion” beast patiently waited in its “repository”, and finally its time has come, and it mutilated their precious files with those horrible “>>>>>>>” symbols, dealing irrevocable damage, destroying hours of work. And it is you who should have abolished the beast weeks ago, yet you seem to somehow collaborate with it. Something is wrong.

I think that the problem lies in anonymity of conflict markers. Subversion shows them like this:

--- .svn/text-base/sandwich.txt.svn-base Tue Dec 11 21:33:57 2007
+++ .svn/tmp/tempfile.32.tmp Tue Dec 11 21:34:33 2007
@@ -1 +1,5 @@
-Just buy a sandwich.
+<<<<<<< .mine
+Go pick up a cheesesteak.
+=======
+Bring me a taco!
+>>>>>>> .r32

Git shows them similarly. I propose that we add the necessary information about who did the change:

--- .svn/text-base/sandwich.txt.svn-base Tue Dec 11 21:33:57 2007
+++ .svn/tmp/tempfile.32.tmp Tue Dec 11 21:34:33 2007
@@ -1 +1,5 @@
-Just buy a sandwich.
+<<<<<<< .mine: DON'T PANIC. http://example.com/resolving.html
+Go pick up a cheesesteak.
+=======
+Bring me a taco!
+>>>>>>> .r32, added by mike at Tue Dec 07 11:00:00 2007

Of course, the information about who and when did the change is readily available from revision identifier, but the explanation could never hurt. It directs attention from the formless “Subversion”, or “Them”, to actual Mike, whom they could talk to. Second, the empty space could be used for some explanation, as set up by repository administrator.

If you like this idea — please, spread a word. Every version control system could be changed this way. And the change is almost purely cosmetic and I believe not very risky (though third-party tools could rely on conflict markers format too much).

What do you think?

Yesterday Git 1.6.0 was released.

Please read full announcement and changelog.

Continuous Integration was popularized by Martin Fowler and Kent Beck. It is so tightly integrated with version control system (”Maintain a Single Source Repository”, “Everyone Commits Every Day”, “Don’t Commit Broken Code” are basic practices of CI), that it clearly deserves mentioning here. Martin Fowler wrote an overview article: “Continuous Integration”.

“Continuous Integration: Improving Software Quality and Reducing Risk” is the book by Paul Duvall which was published in Martin Fowler signature series. You may find sample chapters online:

• Chapter II. “Introducing Continuous Integration” on the book website http://integratebutton.com/;
• Chapter VI. “Continuous Testing” on Infoq.com.

Dave Dribin wrote a couple of posts on choosing between the usual suspects: Mercurial, Bazaar and Git. Well-written, recommended.

Read at: Choosing a Distributed Version Control System; follow-up: Why I Chose Mercurial.

We’ve reorganized the information from the famous Better SCM: Comparison project, and presented it in a more useful way.

Announcing: Version control systems comparison 2.0.

You may compare any number of systems against each other. See for example:

• CVS vs Subversion;
• bzr vs Mercurial;
• Subversion vs svk;
• Distributed version control systems;
• Choose your own set of version control systems;

TODO: add (at least) Git, PlasticSCM and Microsoft TFS information to the original Better SCM database and re-import it here. Stay tuned for updates.

Damon Poole (CTO of AccuRev) wrote a teaser post in AccuRev blog about AccuRev streams: Damon Poole: “Streams vs Branches”.

This article links to a whitepaper: Damon Poole: “Stream-based architecture for SCM.

As far as I understood from the first reading, idea of streams is very straightforward and simple concept making “streams of development” a first-class object in AccuRev repository. Streams are very easily presented on UI level, making them easily understood for software developer and release manager. Branches, tags, and private workspaces could be superseded by various flavors of streams.

E.g. “Release 4.0″ is a stream. “Release 4.0.1″ is the child stream. Changes made in 4.0.1 could be “promoted” to 4.0. When we start the “5.0″ line of development, it automatically gets everything that was promoted to 4.0, either from older version or from bug-fix version (4.0.x).

I understand that streams could be enormously useful if they actually do the merging well. Technically this is handled easily by modern standards. Something like this could be done (and may be is already done) in many GUI clients for most open source version control systems.

Second part of the whitepaper is dedicated to AccuRev TimeSafe, which is the underlying repository format. I have to remark that the article only compares TimeSafe features with CVS and ClearCase repository features. Those are embarrasingly easy targets for criticism. Why are modern repository formats such as Subversion FSFS and Git not mentioned? Are they technically superior? ;)

Article on Timesafe: Damon B. Poole “The Timesafe Property – A Formal Statement of Immutability in CM”.

See also: DaveOnSCM: “Agile: Branches vs. Streams”.

Second chapter in O’Reilly book “Beautiful Code: Leading Programmers Explain How They Think” was written by Karl Fogel, and is called “Subversion’s Delta Editor: Interface as Ontology”. Karl has put this chapter online under the free license.

Read this chapter online: rants.org: “Beautiful Code Chapter Now Online”.

Robin Luckey of Ohloh.net gathered information on oldest public source code repositories. Top three are:

• BRL-CAD, started in April 1983;
• GNU Emacs, April 1985;
• GCC, the GNU Complier Collection, November 1988;

Read the article at Ohloh.net: “The World’s Oldest Source Code Repositories”.

Short talk on Subversion misuse: “Subversion Worst Practices”.

Important opinions from Subversion developers:

Karl Fogel: “Subversion, decentralized version control, and the future”

Ben Collins-Sussman: “The Risks of Distributed Version Control”