Musings on personal repos
2019-10-10
(This is going to be a ramble; you’ve been warned.)
When I started keeping stuff in version control, I made two design decisions that… may have been suboptimal, although there havecertainly been upsides.
First, I used mercurial as my version control system of choice. I think this was a good choice, actually; it was easier to learn than git, and remains more intuitive for me. Unfortunately, hosting options for mercurial have always been a bit thin, so I ended up hosting all of my private repos on an internal box that just had ssh and mercurial set up. For public repos, I would either use Bitbucket or deviate from my convention and use git. The situation was brought to my attention again recently with Bitbucket cutting support for mercurial, although now there’s sr.ht to serve as a (superior) replacement.
Second, I tended to make… well, by definition not monorepos, because there were 4 of them, but at any rate “per-subject” repos rather than “per-project” repos. That is, 90% of my stuff is in the repos “provisioning”, “text”, “dotfiles”, and “misc” (yes, really). So if I wrote a new stand-alone script, I’d stick it in misc. Configs that go in my home directory live in dotfiles. System configs are deployed by ansible from provisioning, which also houses Dockerfiles, terraform stacks, semi-manual provisioning shell scripts, packer configurations, etc. And… I really don’t regret this. If I were to do it all over again, I might consider going full monorepo rather than splitting it into four, but they evolved organically as I moved things to using version control, and fully merging them would be a pain now.
In practice, this is actually a perfectly reasonable arrangement… as
long as I’m the only one using it. I’ve even fixed the pain point of
setting up on a new machine by just having Ansible check everything out
and then invoke the shell script that symlinks my dotfiles into place.
The catch comes when I want to share something with the world. So
recently I wanted to publish some of my Dockerfiles. If each such
project were, say, a repo hosted on GitHub, then I would just set the
repo to be public and I’d be done. But each project is actually just a
subdirectory in a mercurial repo that isn’t hosted in a way that readily
supports public access at all. So what I actually ended up doing is
creating new git repos on GitLab, cloning the empty repo down, and then
hand-picking files over. This, to put it nicely, is less than ideal. At
a minimum, I’d like to set up some sort of tooling to automatically sync
the git repos with matching subdirectories in mercurial, and then… I
don’t know, set up a commit hook to invoke it automatically? Maybe I
should just tear things apart into truely separate repos per-project and
be done with it. This would especially make sense for things using
GitLab’s CI pipelines; having a .gitlab-ci.yml file in a
subdirectory under a mercurial repo hosted on my own system is… well,
entertaining, at least. Alternatively, maybe it is perfectly sufficient
to set up some tooling to keep one foot in each world; I could even use
--work-tree and/or --git-dir to directly have
git track files in mercurial.
So anyways, this wasn’t really going anywhere; I just wanted to ramble a bit about the mess that is my collection of repos. I suppose the bright side is that I only have to wrangle 2 version control systems (git and mercurial) across 5 providers (Bitbucket, GitHub, GitLab, sr.ht, and my own machine); if I had actually gone with the impulse to try darcs or fossil, this would be even more, ah, fun:) If there’s a real lesson here, it’s probably that hindsight really is everything; if I could sit down with myself from 5 years ago I would just tell him to make a monorepo and write a sync script to trade with git repos and be done with it. (And if I could go back 10 years I would forcefully explain that younger-me really needs to just learn version control because it’s absurd that it took me so long to start using it.)
I might just do that now, actually; how hard can it be?
LOL.