Planet SCM

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”

Tim O’Reilly, together with Karl Fogel, discussed the idea of version control for U. S. Congress.

It turns out that Tasmania seems to have implemented something similar, as described in article by Timothy Arnold-Moore “XML for legislation drafting, management and Web delivery—How structured document representation facilitates automatic processing”, published in Novemeber 1998 (found via Bex Huff).

We have already covered similar topic back in March: Slashdot: Source Control for Bills in Congress.

Mark Shuttleworth (of Thawte, Ubuntu, and Canonical fames) wrote four posts on rename tracking feature in version control systems, and its impact on merging as a social process.

Read at his blog:

• “Renaming is the killer app of distributed version control”;
• “Further thoughts on version control”;
• “Choose lossless VCS if you have that luxury”;
• “Merging is the key to software developer collaboration”;

Those posts caught a lot of attention back in June, but frankly it seems to me the issue is somewhat overrated (but nevertheless a recommended reading). Mark’s Canonical Ltd. supports the development of Bazaar. Bazaar has the discussed feature of merging with renames tracking. Git does not have it, but it has another argument in this discussion: huge merging traffic — Linux kernel development is all about merging, and the codebase is huge. So, I guess this feature is not that crucial: Linus is well-known by his uncompromising approach to tools.

Ian Clatworthy, one of the primary developers of Bazaar, has posted a series of articles on version control in broad modern context.

His primary thesis is:

Beyond market acceptance, there are 6 main criteria I consider when evaluating collaboration tools:

1. Reliability
2. Adaptability
3. Usability
4. Extensibility
5. Integration
6. Administration (including Total Cost of Ownership)

Read the whole series at:

• “Version Control: The Future is Adaptive;
• “It Takes a Community to Raise Great Software”;
• “Wanted: Rock Solid Version Control”;
• “Version Control: Plug-ins vs Toolkits”;
• “Version Control: Design for Integration”;

Couple of memorable quotes:

Likewise, in the field of collaboration, I think there are 5 interesting numbers: 1, 2, 10, 100 and 1000. These numbers represent:

• an Individual
• a Partnership
• a Team
• a Company
• a Community

[…]

As a young software engineer back in the early 90s, 10s of thousands of people woke up to cold showers in Sydney one morning because of a corner-case bug in my code controlling the off peak hot water system. That sort of event tends to have a life long impact on how one designs software!

PJ Hyett has created an impressive plugin for Ruby on Rails, called auto_migrations.

It deduces changes between the db/schema.rb and the current database schema, and executes the appropriate commands to bring the latter in sync with the former. It supports creating tables, adding, changing, and removing fields, adding and removing indexes. It also allows you to create the real migrations based on schema changes.

Read more at author’s blog: Err the Blog: “Automatically”.

Git 1.5.3 was released by Junio Hamano on Sep 3rd. Read more at:

• few selected new features by Garry Dolley;
• more on git stash feature, by Jonathan Tron;
• original announcement by Junio Hamano, with detailed changelog;

Garry Dolley posted the module for Capistrano (that’s Ruby on Rails deployment tool) which allows it to use Git as the source control system.

Read more and download at “Capistrano 2.0 with Git shared repository”.

Zack Rusin created useful Git cheat sheet.

See “Git cheat sheet” for several sizes.

There is also a similar Mercurial cheat sheet at http://www.ivy.fr/mercurial/ref/v1.0/

Thank you, Robert.