Channels ▼

Open Source

What's New in Subversion 1.7

Merge Tracking Improvements

Every major release of Subversion (and many minor ones) since version 1.5.0 delivered incremental improvements to Subversion's merge tracking feature, and this release is no exception. Since the 1.6.0 release, Subversion's developers have identified and fixed nearly 80 bugs and enhancements related to Subversion's ability to efficiently and correctly track and manage merges of changes between branches. Many of those fixes have already been released to the public via the subsequent 1.6.x releases, but Subversion 1.7.0 alone provides more than 40 of these improvements.

One of the key improvements is the handling of merge tracking metadata on working copy paths under a merge target (known as "subtree mergeinfo"). No longer does a merge unconditionally update all subtree mergeinfo to describe a merge. In 1.7 only the subtrees affected by the merge are updated. This addresses a common complaint about the amount of "noise" in the form of mergeinfo changes produced by relatively simple merges.

With Subversion's widespread (and growing) adoption in enterprise environments — many of which employ heavily branch-centric development processes — every improvement to this feature is a welcome one.

Improved Difference Marshaling

Experienced Subversion users are familiar with Subversion's built-in "diff" functionality, which displays line-based changes between two files or two versions of the same file. This information is, of course, useful to the humans reading it ("What changes did I make to this file's contents?"), but is also presented in the standardized unidiff format, which can be stored in a patch file, shared with another user, and then parsed by a "patch" program in order to apply those same changes to a different copy of the file. Unfortunately, "patch" is concerned only with content changes to text files. It knows nothing of the other types of changes that can be represented in Subversion working copies: changes to file and directory versioned properties; changes to the directory hierarchy caused by adding, removing, and copying items around; changes to the contents of non-human-readable files; and so on.

Subversion 1.7 offers some improvements to its "diff" functionality, enhancing the output format to represent changes to versioned properties in a more reliably machine-parseable way and offering an output mode that is compatible with the popular git version control system. But those improvements alone don't necessarily help other Subversion users apply someone else's patch files to their own working copies. So Subversion 1.7 also introduces built-in support for parsing its own "diff" output and applying the changes found there to a target working copy. Today the new "svn patch" command can parse and apply content modifications made to human-readable files, modifications to Subversion file properties, and simple file additions and deletions. Future releases of Subversion are expected to deliver the completion of this feature, ultimately allowing the ability to reproduce every type of local change that Subversion allows in its working copies.

... And Then Some

It goes without saying, but good developers can fix a tremendous number of bugs in two years' time. The CHANGES file provided with the source code distribution of Subversion 1.7 lists over 150 improvements to the software, and those are just the ones deemed worthy of mention. And while this article covers the most high-profile features of the release, that coverage is far from exhaustive. Subversion 1.7 offers many more improvements, perhaps one of which is precisely the one you've been waiting for. For more information, consult the project's official release notes online.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.