Next month, if all goes well, developers working on the open-source Subversion version control system will resolve a "critical bug" that has gone unaddressed for 15 years.

Issue 898, created on September 11, 2002, proposes a change in the way Subversion handles file renaming. Presently, as has been the case for more than a decade and a half, the version control software renames files by copying them to a new location and then deleting the original files at the old location.

As a way to implement file renaming on a desktop computer, this might be acceptable. But for a version control system, designed to track files over time in relation to all the other files in a code repository, Subversion's approach leaves something to be desired.

The problem is that copying an old file into a new one leaves the old file's revision history behind. And barring unforeseen circumstances, it's an issue that itself will soon be history.

A Reg reader alerting us to the long-awaited patch heralded the glorious event thus: "Inspired by that observation and the vast number of Git users satisfied with how it handles file-renaming, the new set of patches will switch Subversion to also track content of files, thereby making the hoary, barbate issue 898 academic."

That may be overstating the scope of the solution. While Subversion 1.10 will address the problems raised in issue 898, further changes are anticipated.

Stefan Sperling, an open source consultant and contributor to Subversion – which is overseen by The Apache Foundation – said in an email to The Register that issue 898 is very broad in scope. "It is about server-side file system changes to facilitate 'true renames,' which would indeed be an invasive change," he said, noting that there's no consensus about what 'true renaming' really means in the context of a version control system.

"While the problems caused by issue 898 are widely acknowledged and well understood by SVN developers, there is no unilateral opinion on how these problems should best be dealt with," according to Sperling. "Implementing renames in a 'perfect' way for Subversion poses a very difficult set of problems."

As a start, the plan is to introduce a new "conflict resolver" that automates the resolution of tree conflicts.

"We aim to provide a better end-user experience for the class of problems which result from a lack of rename handling, and also address cases which do not involve renames, such as two different branches adding a new file or directory at the same path," said Sperling. "All this was implemented entirely on the client side. There are no server-side changes involved at all, which makes this a relatively non-intrusive change."

Sperling noted that some work by contributor Julian Foad to address the challenge of merging renames between branches through an "element-based merge" remains unfinished and won't make it into the 1.10 release.

As a preview of how renaming will work, Sperling offered an example in which a file was renamed in the repository and locally modified in the working copy. The update, he said, requires no user interaction in this instance and the local change automatically gets incorporated into the new file.

$ svn diff Index: alpha =================================================================== --- alpha (revision 2) +++ alpha (working copy) @@ -1 +1,2 @@ alpha +a new line $ svn --version -q 1.10.0-dev $ svn diff Index: alpha =================================================================== --- alpha (revision 2) +++ alpha (working copy) @@ -1 +1,2 @@ alpha +a new line $ svn update Updating '.': C alpha A alpha-renamed Updated to revision 3. Summary of conflicts: Tree conflicts: 1 Searching tree conflict details for 'alpha' in repository: Checking r3... done Tree conflict on 'alpha': File updated from r2 to r3 was moved to '^/trunk/alpha-renamed' by stsp in r3. A file containing uncommitted changes was found in the working copy. Applying recommended resolution 'Move and merge': G alpha-renamed Tree conflict at 'alpha' marked as resolved. Summary of conflicts: Tree conflicts: 0 remaining (and 1 already resolved) $ svn diff Index: alpha-renamed =================================================================== --- alpha-renamed (revision 3) +++ alpha-renamed (working copy) @@ -1 +1,2 @@ alpha +a new line $

Sperling cautioned that Subversion 1.10 doesn't yet have a definite release date and that its feature set may still change.

"My personal expectation is that 1.10 will make dealing with renames a lot easier for most users in the most common cases," he said. "There are some edge cases which can't yet be supported in this way (eg, when the user first adds a new directory and then moves files inside of it, rename detection will fail for those files). I also expect that the conflict resolver will keep improving over time." ®