timotei has repeatedly complained about the shortage of technical posts in this blog ever since I became a creative person again, so here is a half-baked record of a thing I am doing.
SourceForge.net became one of the most popular VCS hosting solutions for open-source software back when platforms like GitHub and Bitbucket didn’t exist or weren’t very popular. See, there was a time when people thought Subversion was the best thing since sliced bread— er, I mean, CVS. Yes, the best thing since CVS, a thing that—thankfully—I never had a chance to use.
For anyone who has done anything more advanced with the official Subversion client or used the various APIs available for Python and Perl applications, however, Subversion is a unique kind of software that should inspire university professors to teach courses exclusively dedicated to analyzing the wonderful psychological phenomena involved in the OSS ecosystem’s past decision of adopting the unreliable, inefficient, and overall sloppy heap of ruminant egesta we affectionately call “SVN”.
And for anyone who has been using SourceForge.net since about 2008 for anything other than small toy projects, the progressive degradation of service quality and reliability (except for the File Release System) has become blatantly obvious. I (or AI0867, really) could spend the entire day describing the various ways in which SourceForge.net’s architecture is irritatingly obtuse, so I’ll just refer to my latest foray into the world of cleaning up other people’s mess:
Apparently, when wesnoth-umc-dev was switched to Allura, the upgrade script failed to make a post-commit hook that fits the Allura set-up.― Ignacio R. Morelle (@shikadilord) August 5, 2013
So yeah, fixed wesnoth-umc-dev's SVN web interface at last, after fiddling a bit with the hook scripts. Thanks for nothing, Allura.― Ignacio R. Morelle (@shikadilord) August 5, 2013
Since I am not an active admin of the Wesnoth-UMC-Dev Project anymore, deciding whether, when, and how to switch to a DVCS like Git is not my duty. But that doesn’t mean that I can’t try out possible solutions on my own in the meantime, especially seeing as how Git makes it far easier to push information between repositories and...
... Yeah, I cannot keep pretending I ever considered any DVCSes other than Git for this.
Converting Subversion repositories to Git is no small task. We know this already. Wesnoth-UMC-Dev is even more complicated in that the repository effectively hosts multiple different projects using one or more non-standard file and directory arrangements. But that doesn’t mean converting some of them to Git is not feasible — in fact, this has actually been done before, multiple times: since mid-to-late 2008, I have managed Invasion from the Unknown and After the Storm almost exclusively using Git, by means of the
git svn sub-command. It is doable in principle, but there are a few caveats:
git svngenerates empty/diff-less commits for every SVN revision that exclusively alters SVN metadata (e.g.
svn:mime-type), since that doesn’t have an obvious representation within a Git tree.
git svnadds a rather ugly-looking metadata trail to every commit by default to ease matching of Git commits with Subversion revisions, both for the user and automated tools. Example:
commit 890efb4652c1c27be96de6acec72ceeb0d0178b5 Author: shikadilord <shikadilord@87cc232e-6748-0410-ac04-a3fa75566414> Date: Tue Feb 19 04:04:11 2013 +0000 AtS: bump version from 0.8.5+svn to 0.8.90-svn in the changelog after the Big Merge git-svn-id: svn+ssh://svn.code.sf.net/p/wesnoth-umc-dev/code/trunk/After_the_Storm@17177 87cc232e-6748-0410-ac04-a3fa75566414The metadata in question can be precluded during the git-svn tree generation using the
--no-metadataswitch, but this is not very helpful if one ever needs to trace down old inter-related commits after the conversion!
git svndoes not generate Git tags for Subversion tags, wherever they exist. Why is this? Because the existence of Subversion tags is a malicious fabrication by people who applied the “everything is a file” (or directory) paradigm in all the wrong ways. Oh, come on, don’t look at me like that. Here, have a handkerchief.
The point is, a Subversion tag is no different from a Subversion branch in that it is a directory or file copy operation which allows the result to be modified as many times as necessary without any kind of restrictions. Yes, you can create a ‘tag’ from your development trunk in Subversion and then add new files to the tag or change their content, and so on. Git tags are far more static, and they essentially are annotated references to existing objects; no further changes are possible without editing a given tag to point to a different object.
So, in short, Subversion tags may not always translate to Git tags, so
git svnchooses the lowest common denominator approach and just generates tiny branches from them:
shadowm@nanacore:~/src/projects/After_the_Storm$ git branch -r 1.8 tags/0.1.1 tags/0.1.2 tags/0.1.99.0 tags/0.1.99.0a tags/0.1.99.1 [...]
These issues make it decidedly non-trivial to perform a clean SVN-to-Git conversion using any sufficiently mature repository as basis. Again, with Wesnoth-UMC-Dev there is the added difficulty factor of multiple unrelated projects sharing a single Subversion repository, but
git svn handles this rather well for the specific portions I want to convert.
At this point you have successfully guessed that my ultimate goal is moving Invasion from the Unknown and After the Storm to GitHub for good. That is, unless you have no idea what this is all about and you just landed on my blog by accident; or you have been stalking me all this time without even bothering to learn anything about what I do in Wesnoth.
Creating Git slices for IftU and AtS is actually more feasible than I thought at first, using a little guide vultraz by chance found for me, and
git filter-branch. In fact, last night I managed to turn this into its own standalone Git repository, preserving its entire history sans metadata-only commits. I feel very optimistic after this small test conversion.
But how did I achieve this? What kind of arcane magic was involved in this process? What are the things I did not try yet? What other challenges could there be for converting IftU and AtS to Git?
In the next installment of this new series of blog posts, I shall speak of this and other unfathomable mysteries. Until next time!