Five weeks ago I wrote that direct Subversion support in reposurgeon is coming soon. I’m waiting on one final acceptance test before I ship an official 2.0; in the meantime, for those of you kinky enough to find the details exciting, description follows of why this feature has required such a protracted and epic struggle. With (perhaps entertaining) rambling through the ontology of version control systems, and at least one lesson about good software engineering practice.
For those of you who have been following the development of reposurgeon, a pre-announcement: the next version, probably to be numbered 2.0, will directly read Subversion dumpfiles and repositories.
I’ve got this feature working now – it’s why my blogging has been scant recently – but I intend to have a really good regression-test suite in place and at least one large repo conversion done before I ship it for general use.
Note an important limitation: it will not write Subversion repos. So it will be useful as a conversion tool but not directly as an editor.
Well, I thought I was done hacking on this for a while. Then one of the projects I did a conversion for disclosed the existence of a second repo for their website, which I had to merge into the code repo. As a subdirectory. Which meant pushing all the file paths into a subdirectory. Which meant the new “paths sub” command; I wrote “paths sup” as its natural dual.
Also in this release: automatic preservation of untracked files under git and hg.
reposurgeon 1.8 is out, and with this release it has all the conversion features I’ve been able to think up while doing the last couple of conversions. This version creates real tags from the lightweight tags generated by git-svn, and also consolidates matched D/A pairs from Subversion into renames.
An “edit multiline” variant of the “edit” command zeroes in on commit comments that need to be tweaked into the approved form for hg and git (summary line, plus optional blank line, plus optional details).
The selection-set syntax has a new element: =H selects tip (or H for head) commits.
A new ‘sort’ command can make the DAG after a graft or merge display better in tools such as gitk.
With this release, I think I’m done for a while – barring bug reports, of course. I’m shipped a new version of my DVCS Migration Guide to go with it.
reposurgeon 1.7 is out. Fewer obvious changes this time; the big feature is that it knows how to read and use the CVS revision maps generated by the -R option of git-cvsimport. This means that it can patch CVS revision references into an action-stamp form that makes sense in a VCS-independent way.
This is a request for comment on a convention for uniquely identifying user actions on the Internet. The motivating context was identifying commit changesets in version-control systems in a way independent of the specific VCS. It is anticipated that this format will have uses in recording many other similar sorts of transactions, including actions on web interfaces, where we want a simple cookie identifying “who did this and when”.
I’ve been doing a lot of repository conversions recently, lifting ancient project histories from Subversion or even CVS into modern distributed version control systems. I’ve written about the technical problems with these conversions elsewhere but they also raise issues that are almost philosophical – and not unlike, actually, the challenges natural-language translators face moving a literary work between human languages.
I just released reposurgeon 1.2 and am continuing to develop the tool. In order to test some of the newer features, I’m looking for repository conversions to do. If you run an open-source project that is still using CVS or Subversion, or some odd non-distributed VCS, I may be willing to lift it to git for you (and from git to any other DVCS you might prefer is a pretty small step). Details of this offer follow; limited time only, first come, first served.
(Why have me do it? Well…especially for older projects with a complex revision history, it’s a messy and daunting job. The tools are somewhat flaky, the difference between a sloppy conversion and a good one is significant, and good conversions require experience and judgment.)
OK, I’m officially coming out of my cave now, after what amounted to a two-week coding orgy. I’ve shipped reposurgeon 0.5; the code looks and feels pretty solid, the documentation is written, the test suite is in place, and I’ve got working repo-rebuild support for two systems, one of which is not git.
The rest is cleanup and polishing. Likely the next release or the one after will be 1.0. It’s time for an after-action report. As usual, I learned a few things from this project. Some are worth sharing.