BenBE's humble thoughts Thoughts the world doesn't need yet …

It’s FINALLY done!

GeSHi is now officially available on GitHub!

Before I go into the details I’d like to give a big cheer and lots of thanks to Christian Weiske for taking up the job to convert the repository.

Though this task has been in the queue for about 1.5 years now there were always holdbacks that caused the project to be delayed. The first issue affects the structure of the original repository. While the current conversion was based on SVN it is CVS where GeSHi initially started, thus there already had been a conversion of the repository once. While the transition from CVS to SVN could be done in an almost automated fashion – SourceForge has been offering conversion scripts for automatic conversion back then – it left the repository with some artifacts that made some operations in SVN kinda annoying.

One of them was merging. Although SVN was quite an improvement over CVS in this regard, it still lacked one essential feature: Merge tracking. At least in the beginning when the branching and tracking decisions were initially made. While merge tracking isn’t required in GeSHi’s case it created one annoyance when it was finally introduced: As the SVN history was lacking meaningful information on the history of some files SVN always was failing to find the point when the development branch was initially split from the development trunk. This sucked and thus most part of that information had to be reconstructed by hand; yet SVN didn’t bother and complained nonetheless.

Another thing sucking with SVN was tracking of moved files. And having a long history the GeSHi repository has many such! In fact: The repository had at least 3 distinct root folder structures all of which were so different that applying the default SVN repository structure was more or less guesswork. Well, and actually wrong 😉 For example there once was a time, long time ago in a far far away country down under or nearby, when there was only one version of GeSHi starting in the root directory of SVN. A little while later this version was getting bored and lonely, so a second version was introduced and things were shifted around a bit. While this structure still started near the root it didn’t follow the recommended structure and had no branches, tags and other artifacts SVN tried to manage in the directory tree. Thus a third iteration of sorting things out was performed and below trunk there was now all the code, split into two subdirectories – one for each development strand.

The directory structure at this moment didn’t get any better though: While trunk was split along the development strands you couldn’t easily map things into the branches directory as only one of the strands was present in each branch. And don’t get me started on the tags 😉 There are at least 5 distinct cases when tags had to be reedited for the directory structure to match and things to look like they should.

And while SVN generally has a really good stand on how to handle newlines like Vogon poetry (In short: DON’T!) it’s not what you’d actually want in some cases. Which lead to many other commits which were to correct bad line breaks.

After this being said, let’s head over to the conversion of SVN to Git. First off: This has – as mentioned above – been tried before and when things got serious there were only two tools that survived the loose criteria set for this task:

• Proper understanding of most SVN features
• Way to modify history to fixup some problems with existing commits
• Allow for root directory of imports being moved around
• Allow to reconstruct merges

Of the programs I found for this task only the Git-to-SVN bridge which is part of Git and RepoSurgeon remained. All the other programs listed were either no longer active, were missing features or could not even handle the easy import.

The other program – RepoSurgeon – was actually written to perform cross-VCS conversions and not only understands SVN and Git, but a long list of VCS which it all can cross-convert quite well while taking as many features of each VCS into account as possible. But even with many things considered there was still this wibbly-wobbly timy-wimy mass of GeSHi-SVN repository which instantly triggered a corner case for split-branch commits in RepoSurgeon. And after that bug being out of the way (thanks to upstream ;-)) continued to trigger yet another two bugs.

Thus if you ever consider changing the VCS … DON’T 😉 Well, or really take your time as you’ll need it!