I had said I wasn’t going to do it, but…I experimented, and it turned out to be easier than I thought. Release 2.7 of reposurgeon writes (as well as reading) Subversion repositories. With the untested support for darcs, which should work exactly as well as darcs fast-export and fast-import do, this now brings the set of fully-supported version-control systems to git, hg, bzr, svn, and darcs; reposurgeon can be used for repository surgery and interconversion on any of these.
There are some significant limitations in the write-side Subversion support. For various ugly reasons having to do with the mismatch between Subversion’s ontology and that of git import streams, Subversion repositories won’t usually round-trip exactly through reposurgeon. File content histories will remain the same, but the timing of directory creations and deletions may change. The pathological things known in the Subversion world as “mixed-branch commits” are split apart at Subversion-read time and not reassembled when and if the repo state is written back out in Subversion form. Custom Subversion property settings (basically, everything but svn:ignore, svn:executable, and svn:mergeinfo) are lost on the way through. There are other problems of a similar nature, all documented in the manual.
A particularly unfortunate problem is that mergeinfo properties may be simplified or lost. Mapping between gitspace and Subversion merges is messy because a Subversion merge is more like what gitonauts call a “cherry-pick” than a git-space merge – I don’t have a general algorithm for this (it’s a research-level problem!) and don’t try to handle more than the most obvious branch-merge cases.
It could fairly be alleged that the capability to write Subversion repositories is more a cute stunt than anything that’s likely to be useful in a production situation. While I have regression tests for it that show it works on branching and merging commit graphs, I don’t think I’d actually want to trust it, yet, on a repository that wasn’t linear or only simply branching. Arcane combinations of branching, merging, and tagging could reveal subtle bugs without surprising me even slightly.
Still…having it work even as conditionally as it does seems something of an achievement. Not one I was expecting, either. I really only did it because someone on the Subversion dev list asked about write support, I wanted to reply by listing all the reasons it wouldn’t work – and then I found that I couldn’t actually make that list without trying to implement the feature. It was ever thus…
The only unconquered frontier of any significance in open-source VCSes is CVS, really. No way I’ll do write-side support for that (and I mean it this time!) but I’ve sent the maintainer of cvsps a proof-of-concept patch that almost completely implements a fast-export stream dump for CVS repositories. We’ll see where that goes.
OpenBSD is the only significant and actively-maintained open source project I can think of that still uses CVS, do you know of any other cases?
@Mike Swanson:
Gentoo Linux still uses CVS for its main tree (known as “gentoo-x86” for historical reasons). There has been lots of talk about migrating it to git, but it hasn’t happened yet. (Archives at http://archives.gentoo.org/gentoo-scm/ )
>There has been lots of talk about migrating it to git, but it hasn’t happened yet.
Maybe I could help? It wouldn’t be the first large-project migration I’ve assisted.
Cool!
s/writes (as well as reading)/writes (as well as reads)/
(Not usually quite this pedantic, but that one keeps glaring at me.)
I disagree — this could be very useful for that case where some idiot checks in a multi-gigabyte test result directory.
Read-only support for the major closed-source VCSes would be useful. I guess that the priorities would be Perforce and TFS (both of which do a “free as long as all your code is open-source” licensing and probably have some interesting projects in) and Visual SourceSafe (to rescue people who got lumbered with it in the 90s and have thrown their histories away by doing an import of a release version into something that works, usually svn).
Sadly, I don’t know enough about the internals of these to really make a start – and being closed-source and payable, I’d have to buy the blasted software to even look at it. But next time I know someone who is stuck with code (especially code that’s open source or that they are planning to make open source) in a closed-source CVS, I’ll point them at writing support for reposurgeon rather than trying to do it all themselves.
>I’ll point them at writing support for reposurgeon rather than trying to do it all themselves.
And this generally isn’t difficult. All reposurgeon needs is a tool that can write a fast-import stream from the repository.
Having written the previous comment, I decided to be less frigging lazy.
git-tfs (on github) will extract a full history from TFS to git.
VSS, you’d probably be best going via TFS.
Might be doing that at work – I find it confusing to use TFS there and git at home.
No more smartphone wars? I didn’t think I would miss them, but I do.
Is reposurgeon at least idempotent, though? Is there a guarantee that a repository written by reposurgeon will round-trip?
>Is reposurgeon at least idempotent, though? Is there a guarantee that a repository written by reposurgeon will round-trip?
I don’t know for sure. I think so, but I haven’t tried it.