Subj : Synchronet Source Repository switches from CVS to Git
To : All
From : Digital Man
Date : Sun Aug 23 2020 08:57 pm
After 20 years of using CVS (Concurrent Versions System) to track the changes to the Synchronet source code, documentation, and other files, I'm switching (we're switching) to Git (or rather more specifically, GitLab): http://git.synchro.net
Why? CVS is rather bad at supporting concurrent development (even though it's ironically in its name). Specifically, CVS is bad at branching and merging which needs to be good (fast, reliable, logical) when real concurrent development is occurring. CVS is also *old* by today's standards and pretty much abandoned by anyone who ever cared for it, so there's really no chance of any significant improvements coming to it. :-(
Over the years, I've considered switching to Subversion (SVN), Perforce and even Git. Subversion didn't really address the pain points that we had with CVS while Perforce is commercial and really not cross-platform enough. Today, Git has *all* the momentum and I've been asked many times by Synchronet sysops when will I or why haven't I already switched to Git. So if I'm going to switch to something, Git makes sense.
I didn't switch sooner because the pain of switching (and it is/was painful) was expected to be greater than the pain of continuing to use CVS. A couple of times, we've had to "break everything" in the source repository for a while in order to make significant improvements (the big SpiderMonkey upgrade and IPv6 support both come to mind) and during that time, let everyone know that they probably shouldn't be trying to build or run the code in CVS until it had stabilized. With good branching support (e.g. in Git), that doesn't need to happen ever again.
I had built up a bit of infrastructure (scripting, documentation, processes) around the use of CVS and while some of that was fairly trivial to migrate to Git, other aspects may not be. Of particular concern to me is the lack of a running "revision number" for each file when using Git (and no, a hash is not a revision number in the traditional/useful sense of knowing if rev 1.12 is newer or older than rev 1.02). So although the old CVS revisions are still embedded in the $Id$ and $Revision$ keywords you find in almost all the source code, they are no longer automatically changing (e.g. incrementing) whenever the file is changed in the repository. This is the one downside that I have not yet overcome.
The entire 20 year history of the files in CVS was imported into a new Git repository which I am hosting at https://gitlab.synchro.net:/sbbs/sbbs. All the CVS tags (e.g. release labels) were imported too, but unfortunately with the way I used and abused CVS over the years, none of those old tags are really of much use. i.e. don't expect to checkout an old tag, even "sbbs317b", and be able to build the resulting code without some problem. It's not the fault of Git though, more the inflexibility of CVS.
Git is very different from CVS, but I don't think those differences are going to matter much to most Synchronet sysops. Here's a list of things sysops, *might* care about:
1. With Git, you can't download/clone just a *part* of a repository, you always get it all, including the entire history (> 100MB as of today). If you really just need/want a single file, you can use the web UI at gitlab.synchro.net. However, there's also a benefit: everyone who clones the sbbs repo will now effectively be a "mirror" for the repository. No "git-mirror.synchro.net" necessary. This is what they mean when they say Git is a "distributed system". CVS was a "centralized system".
2. With Git, there are a *lot* of available commands and options and its pretty easy to get a clone of a repo into a weird state that's difficult to wrap one's head around. This is especially true if you're making local changes to the files in your cloned repo, so expect sbbs git-tips to be coming forth soon.
3. With Git, you can't update (pull from the remote repo) just a subset of the files that you have cloned; it's all or nothing. This means that if you have modified any of the files in your clone of a repo, those changes will have to merge nicely with the upstream changes or you'll have "merge conflicts" to deal with. And many of the Synchronet run-time files (e.g. ctrl/*.cnf, *.ini) aren't ameniable to merging, so you must copy many of the files from the repo before you can effectively use them with a running sbbs. The *nix installer has been updated to do this automatically (hence the new "sbbs/repo" dir that is now created when you use install/GNUmakefile).
4. The Git web interface that I've chosen (GitLab, which is a lot more than just a web UI), is a lot heavier and featureful than the old viewcvs/cvsweb scripts. Some of those features are going to be cool, but in general it's not quite as "snappy" as the old web UI was and it doesn't *appear* to have some of the features that I've become accustomed to (e.g. sorting a list of source files by last-modified date).
On the other hand(s), developers today are using Git in the work-place and for their hobby projects, so that's what everyone (the devs) have become accustomed to. So hopefully this change inspires some renewed interest from other developers that haven't been active in a while (and universally, nobody "liked" using CVS).
For myself, I have a "branch" of the code that I had been working on last year while revamping the file system (and yes, supporting long filenames) and I'll be putting that into an experimental Git branch that I can now easily merge with all the *other* changes that have happened in the past year. Yeah!
So, thank you Linus (and friends), this will work nicely. :-)
digital man
Sling Blade quote #26:
Karl: kaiser blade, ax handle with long blade on it shaped kinda like a banana.