Going back to Subversion
14 January 2023Back in 2021 while I was away from my main personal desktop for an extended period of time due to travel restrictions I experimented with switching my internal website repository over from Mercurial to Subversion. Even though I had remote access to that system I needed to locally keep track of changes so that I could just copy over the files that had changed when the time came for me to return, and I wanted to see whether Subversion was still worth using or whether I should just switch over to Git exclusively. Having built myself a new personal workstation I decided as part of the data migration and tidy-up process I would switch my website and electronics repositories over to Subversion.
Mercurial falling out of favour
When I first looked at distributed version control I opted for Mercurial over Git because at the time Git was a Linux-only thing and was much more complex to both get up-and-running and to use. It was only in 2013 when I was introduced to continuous integration and Agile/Scrum that I really got to understand Git's work-flow and doing the same things in Mercurial involved jumping through hoops. I also came to miss Git's ability to stage files for commit rather than having to list all the files to be committed on the command-line, and at some point in 2014 I wrote a Mercurial extension that implemented a form of this. By this point Mercurial was on its way to losing the mind-set war to Git if it had not done so already and by 2019 Bitbucket had dropped support for it. De-facto I was using Git a lot whereas I was only making basic use of Mercurial for some personal projects, and I often found myself thinking “What is the equivalent of Git's..” and this sent my liking of Mercurial went into decline. Finally I concluded that it would just be a load of extra effort to continue using Mercurial at all.The motivation to switch
Ironically I originally kept website-related files in a Subversion repository but for reasons long-forgotten I switched over from it to Mercurial — I suspect it may have been in order to just use the one version control system since I used Mercurial a lot at the time for software projects. The website repository is now a bit of a mess including some now long-decommissioned mini-websites mostly dating back to when I was in University, and I planned to tidy it all up before migrating it to a new computer workstation, so this is part of a much bigger clean-up of my personal workstation's home directory. It made sense to have a combined cleanup and switch-over to another version control system. Part of the cleanup is to make backups easier and having a complete snapshot of my previous personal workstation on Blu-Ray means I can go ahead and remove all the material that corresponds to websites I have since either redesigned or shut down.My work-flows
The big reason for choosing Subversion over Git is the former allows sub-directories to be checked out separately, as well as allowing sections of the same repository to be checked out with a different revision number. This is especially useful when multiple projects are kept in the same repository, which historically is what I have done. With Git working on to different things within the same repository at the same time would involve either switching between branches or cloning a second copy of the repository, which for my purposes neither is a good approach. Aside from using it for websites the other thing I still use Mercurial for is my printed circuit board repository.Website drafting procedure
My work-flow for web articles is to use a separate Bitbucket repository for drafting, since I normally draft them as stand-alone HTML files rather than in the format my web-server setup uses. It is only at publication time that they are pulled into my main website repository, so Subversion's “inferior” support for different work-flows is irrelevant to my requirements. Commits within this main repository generally correspond with synchronisations with my live webserver rather than different stages of writing so Git being the far superior tool to aid development is simply of no help to me here — Git does indeed help with writing but I have a separate repository for that.I don't know the underlying details but Subversion to my knowledge is a lot better at handling binary files than Git, which is a major plus point given the large number of images — and a few videos although the vast majority have been excluded — that my website has. In fact binary files are about 99% of the total file space used. I almost always do drafting and development outside of this main repository so I have no interest in things like branching, and for my purposes Subversion being essentially a versioned file-system suits me fine. There are Git extensions that are designed for handling large binary files but to me that just seems like extra hassle.
Circuit board repository
Subversion's model of branches just being a copy of a directory — the thing about having sub-directories namedtrunk and branches is just a convention — is pretty close to my approach for my PCBs.
Sub-directories correspond to a revision of the design files that have been sent off for fabrication, and I keep them in separate folders because the only sane way to compare such board revisions is to open them both in KiCad at the same time.
Putting PCBs into a repository is really a back-stop against seriously screwing things up rather than to track fabrication revisions, and branching/merging is something that is simply not going to be done with PCB design files because the work-flow for writing program source code does not really work with PCB design files that are generally not edited by hand.
Multiple projects in the same repository
Back when I started with CVS one thing I really liked was being able to have multiple projects in the same repository and this is something that can easily be done with Subversion as well, but with both Mercurial and Git anything other than one project per repository becomes a pain. I used to keep all my PCBs in the same Mercurial repository but since checkouts affected all sub-projects, working on more than once quickly became very annoying. At some point I had had enough and split the repository up so that each PCB had its own. Since many PCBs were designed in a single sitting I did not even bother making a mini-repository for some of them.Where is .svnignore?
For files that should be disregarded by version control Mercurial has.hgignore and Git has .gitignore but in Subversion files that should be ignored are indicated as a property attached to a directory, and in practice it is a bit of a pain to use.
Yes there are ways of editing a directory's svn:ignore but it being different to basically every other version control system I have ever come across is irritating.
Thankfully I have had little need so far for my website and circuit board use-cases because unlike program code there are not nearly as many files being generated that need to be kept out of version control but it is one of those idiosyncrasies that already makes me wonder whether Subversion is worth the effort.
Time will tell.