> What SVN didn't fix was the fundamental centralized model. You could not commit without a network connection. The repository was still a single server. "Working offline" meant "reading-only", you could browse history but not record any new work, and the day the server was down was the day the whole team waited.
FWIW this is how most projects work anyway. And IMO Subversion is still the best VCS when you have a lot of large binaries (the various extensions to Git like git-lfs are just hacks that graft a separate half-baked version control system to it and add further complexity to an already annoyingly complex system). I remember working at a gamedev company in early 2010s and out of curiosity i tried to put everything in the 250GB perforce workspace in a git repository only for git to choke and die before it managed to do anything. In comparison, ~5-6 years earlier i worked briefly at a game porting studio where every single game they had ported (which i'm almost certain went all the way back to the 90s), including all data and source (and these were AAA games, not tiny indie games), were into a single Subversion server.
Unfortunately Subversion lost the VCS fashion wars and nowadays it barely seems to have any development. I still use it for a few projects where i do have a lot of binary stuff, but most new things are in Git. I also have a bunch of stuff in Fossil (which also did handle binary files better than Git when i tested it years ago, though not as good as Subversion or P4) but nowadays i convert them to Git when i need to share because, well, pretty much everyone expects Git (and projects such as Codeberg and Forgejo make sharing and self-hosting easier).
Ironically the "fundamental issue" mentioned above was solved not too long ago with Subversion as nowadays you can have multiple "changelists" and each changelist is a full (hidden) SVN repository by itself, allowing you to do commits (as "shelving") and such locally and then push to remote when you're done. AFAIK changelists can also coexist (unlike Git where you can only work at one branch at each time). Unfortunately since Subversion is basically barely held together, only the command-line UI provides that functionality (at least in FLOSS clients) and even TortoiseSvn didn't seem to support it last time i checked.
Our main repo has git history back to 1985. RCS to CVS to git. Each step was lossless. I don’t remember the exact tool, but the CVS to git step was a fantastic Ruby program. It was incremental and each night I had a cron job that would update a checked out copy of the sources on the git side and diff with a copy from CVS. After 6 months I had confidence and the training of everyone was complete and we switched over.
I sometimes wonder what would have happened if Atlassian had stuck with Mercurial support on Bitbucket - I don't think they can pretend that switching to git did very much for them. I love(d) Mercurial, and particularly TortoiseHg integration on Windows.
I worry llm will increase inertia and make more difficult to adopt new technologies.
But who knows? Maybe it would lower the barrier instead. If switching to fossil is just one agent.md instruction away and it brings useful features with minimal effort, it might be an easier sell than without them.
After all, the new generation of programmers won't bother learning git anyway.
I use Subversion w/o a server too. You can have your repositories locally (file:///Path/to/repository). All my own (single man) projects are in local SVN repositories. For my use case git is just too much extra friction, and I still love to have my one single unique global revisions number that is linearly increasing with each commit. :)
I loved the simple increasing numbers of Subversion. This was better then CVS "ad-hoc" versioning and also far better then git's hashes. Single numbers are easy for humans. I would love git would make it possible to work that way (there is one way: `git describe` can show something like "v1.0.4-14-g2414721" which means "14 commits ahead of tag v1.0.4".)
Some form of "increment authority" that simply appends to a list of hashes whenever it encounters a commit not yet on the list? Then you could use URI like $authorityhost/orderedcommits/$number as synonyms for the hashes. Multiple increment authorities would not necessarily have them in the exact same order (and "current latest" would likely differ by an order of magnitude or two after some time if you ever had multiple authorities), but it would still provide a lot of intuitive understanding.
I wonder how the tag mechanism would perform if you just burned it with this content. I suspect that it would not perform well...
Mercurial has serial numbers which work like this ("revision numbers"), but you can only see your local repo's serial number. There's no concept of a public revision number authority.
There were several proprietary systems in the late 1980s and early 1990s. The one I remember was DSEE from Apollo Computer. It was integrated with the file system such that commits and branches worked like zfs snapshots. You could just "cd" to whatever tag, branch, or individual commit you wanted. No checkouts required. Very cool, I wish we still had that today. DSEE was spun off as Clearcase, acquired by IBM, then I don't know what happened to it after that.
That sounds awesome. A bit like plan9 philosophy "everything is a file". I wonder whether one could implement something like this with fuse+git (gitfs doesnt allow this, cf https://gitfs.readthedocs.io/en/stable/mount_options/)
That would be very easy to do with FUSE. I would be amazed if it hasn't been done.
I doubt it's really that useful though - it would be difficult to make the filesystem mutable, which means anything that puts caches or build files in the tree (which is most things) wouldn't work.
With a thin layer of tooling, you could probably build a zfs CVS very easily. There's zfs send and each version is available under .zfs so you could use the patch/diff tool to see different versions and restore to older versions.
Most surprising thing from this article is that svn’s reign was only two years. I vividly remember using it for much longer than that, but at the same time, adopting git almost as soon as it arrived.
It’s probably my memory playing tricks and svn was indeed a short term endeavor.
svn was absolutely in common use for a lot more than 2 years. I would totally believe that cvs was still in wider use though as there was sooo much legacy software hosted on it.
I was convinced that VMS's versioned files thing was DEC's cunning plan to sell more disk drive space (though I didn't and still don't know what the underlying mechanism was) - I was quite glad when I learned how to turn it off, though.
At the start things move much faster and changes are more impactful, but the start is ultimately much shorter than the rest of the lifecycle. That's why a lot of the stories you read about tech are about the early years (let's say 5-10 years, chronologically) and less so about the mature years (which can span 3+ decades, chronologically). So the early period has outsized visibility because it's cooler, I guess?
* * *
Using SCMs as an example:
SSCS - 1972. But at that point there was no internet and the number of computer users was minuscule. So SCCS is just a curiousity, a footnote, probably used by 0.000001% of Git users. So at this point for most practitioners SCMs basically don't exist.
RCS - 1982. See SCCS. SCMs still practically don't exist for most practitioners.
CVS - 1986. Now the internet is getting started and the number of computers in the world has increased by orders of magnitude. Even so, adoption of core development technologies like SCMs is slow and yes, it took CVS at least 10 years to become somewhat established. Even at this point, probably at least 50% of software developers still don't use SCMs (especially less professional ones). Visual Source Safe runs in parallel to CVS, with its own problems described in the article.
SVN - 2000. The internet is in full swing, computers are ubiquitous, things are really moving. It's super hard to evaluate how many developers still don't use SCMs, but the number is going down (maybe 30-40%?) and SVN is taking the world by storm. Even after the launch of Git in 2005, until at least 2009-2010, SVN had a solid shot at winning. It's tooling was much better, especially the GUIs, TortoiseSVN & co.
Git - 2005. Git is launched in roughly the same era as SVN, just towards the end. Once Github gets going it starts to take over the SCM scape, primarily from SVN, sometimes from CVS, Perforce, and also from non-SCM people.
So, if you look at the real dates implied above: CVS, SVN, Git are widely adopted in about a 10-12 year span (something like 1998-2000 to 2008-2010). Then we reach the current mature (monoculture?) stage where we're already at least 16 years in and it's quite likely this phase will last decades.
This story has happened for lots of tech. Many different PC OSes during the 1970-1980s, then basically only 3 since about 30 years - 1995 (Windows, MacOS, Linux).
Many CPU architectures during the 1970-1980s, then basically only 2 since about 30 years (x86, ARM - maaaaybe RISC-V).
More than technologies, what really evolved were the ideas on how to work and manage SCM systems. Things like atomic multi-file commits, using unified diffs, management by "patch queues" more than simply merging branches ad-hoc, and of course decentralized SCMs
I have a silly little wiki engine I made 20 years ago. It was an exercise in trying to better learn the traditional unix text processing tools. So the page templates were in m4, sed and awk did their traditional heavy lifting for request parsing and page generation. and page history was provided by rcs. Which fit better than cvs because it provides a history per file.
The whole thing is really the mother of all injection vulnerabilities but I am still half tempted to try and spin it up once more and see what happens if i put it on the public web.
Killed themselves after using it for fifteen minutes. I used to have to teach a commercial "Intro to Unix" course which had a section on SCCS - shudder!
I don't know - RCS just made more sense to me. And I really disliked RCS. You know some things are bad when something like CVS seems all warm and cuddly in comparison.
> I'd have thought that alcoholism would have been enough to numb the pain.
You may be right - it would certainly explain some aspects of my life since those days ;)
Web design tip: don't have animations within a short distance of text, as human eyes evolved to follow the flashiest/fastest-moving thing around, which makes such text literally illegible to many of us. This particular site takes the cake in that regard by animating the whole page background.
True, but the site is called Evil Genius Labs for a reason. And it's not too hard to switch off, there's a clear prompt in the bottom right corner. (Didn't try mobile.)
> What SVN didn't fix was the fundamental centralized model. You could not commit without a network connection. The repository was still a single server. "Working offline" meant "reading-only", you could browse history but not record any new work, and the day the server was down was the day the whole team waited.
FWIW this is how most projects work anyway. And IMO Subversion is still the best VCS when you have a lot of large binaries (the various extensions to Git like git-lfs are just hacks that graft a separate half-baked version control system to it and add further complexity to an already annoyingly complex system). I remember working at a gamedev company in early 2010s and out of curiosity i tried to put everything in the 250GB perforce workspace in a git repository only for git to choke and die before it managed to do anything. In comparison, ~5-6 years earlier i worked briefly at a game porting studio where every single game they had ported (which i'm almost certain went all the way back to the 90s), including all data and source (and these were AAA games, not tiny indie games), were into a single Subversion server.
Unfortunately Subversion lost the VCS fashion wars and nowadays it barely seems to have any development. I still use it for a few projects where i do have a lot of binary stuff, but most new things are in Git. I also have a bunch of stuff in Fossil (which also did handle binary files better than Git when i tested it years ago, though not as good as Subversion or P4) but nowadays i convert them to Git when i need to share because, well, pretty much everyone expects Git (and projects such as Codeberg and Forgejo make sharing and self-hosting easier).
Ironically the "fundamental issue" mentioned above was solved not too long ago with Subversion as nowadays you can have multiple "changelists" and each changelist is a full (hidden) SVN repository by itself, allowing you to do commits (as "shelving") and such locally and then push to remote when you're done. AFAIK changelists can also coexist (unlike Git where you can only work at one branch at each time). Unfortunately since Subversion is basically barely held together, only the command-line UI provides that functionality (at least in FLOSS clients) and even TortoiseSvn didn't seem to support it last time i checked.
Our main repo has git history back to 1985. RCS to CVS to git. Each step was lossless. I don’t remember the exact tool, but the CVS to git step was a fantastic Ruby program. It was incremental and each night I had a cron job that would update a checked out copy of the sources on the git side and diff with a copy from CVS. After 6 months I had confidence and the training of everyone was complete and we switched over.
I sometimes wonder what would have happened if Atlassian had stuck with Mercurial support on Bitbucket - I don't think they can pretend that switching to git did very much for them. I love(d) Mercurial, and particularly TortoiseHg integration on Windows.
Fossil supports wiki, forum, issues
but thing is, aren't coding agents tunned for git based workflows? many agents use git trees right?
so it's unlikely that any git alternative will pickup from here?
I worry llm will increase inertia and make more difficult to adopt new technologies.
But who knows? Maybe it would lower the barrier instead. If switching to fossil is just one agent.md instruction away and it brings useful features with minimal effort, it might be an easier sell than without them.
After all, the new generation of programmers won't bother learning git anyway.
If they had, I wouldn't have switched to Sourcehut, at least not for a while.
Though at some point I would have realized that Atlassian was the wrong fit for my needs as a single-dev, no-AI project and switched.
I use Subversion w/o a server too. You can have your repositories locally (file:///Path/to/repository). All my own (single man) projects are in local SVN repositories. For my use case git is just too much extra friction, and I still love to have my one single unique global revisions number that is linearly increasing with each commit. :)
I loved the simple increasing numbers of Subversion. This was better then CVS "ad-hoc" versioning and also far better then git's hashes. Single numbers are easy for humans. I would love git would make it possible to work that way (there is one way: `git describe` can show something like "v1.0.4-14-g2414721" which means "14 commits ahead of tag v1.0.4".)
Some form of "increment authority" that simply appends to a list of hashes whenever it encounters a commit not yet on the list? Then you could use URI like $authorityhost/orderedcommits/$number as synonyms for the hashes. Multiple increment authorities would not necessarily have them in the exact same order (and "current latest" would likely differ by an order of magnitude or two after some time if you ever had multiple authorities), but it would still provide a lot of intuitive understanding.
I wonder how the tag mechanism would perform if you just burned it with this content. I suspect that it would not perform well...
Mercurial has serial numbers which work like this ("revision numbers"), but you can only see your local repo's serial number. There's no concept of a public revision number authority.
My release code uses `git rev-list --count $tag` to output the release number.
Yes but the .svn dirs everywhere keep being annoying
git rev-list --count HEAD
There were several proprietary systems in the late 1980s and early 1990s. The one I remember was DSEE from Apollo Computer. It was integrated with the file system such that commits and branches worked like zfs snapshots. You could just "cd" to whatever tag, branch, or individual commit you wanted. No checkouts required. Very cool, I wish we still had that today. DSEE was spun off as Clearcase, acquired by IBM, then I don't know what happened to it after that.
That sounds awesome. A bit like plan9 philosophy "everything is a file". I wonder whether one could implement something like this with fuse+git (gitfs doesnt allow this, cf https://gitfs.readthedocs.io/en/stable/mount_options/)
That would be very easy to do with FUSE. I would be amazed if it hasn't been done.
I doubt it's really that useful though - it would be difficult to make the filesystem mutable, which means anything that puts caches or build files in the tree (which is most things) wouldn't work.
I did a very quick search. First result: https://github.com/csutorasa/git-fuse
With a thin layer of tooling, you could probably build a zfs CVS very easily. There's zfs send and each version is available under .zfs so you could use the patch/diff tool to see different versions and restore to older versions.
Microsoft Visual SourceSafe worked like this, but badly.
Sounds like the “jj edit” command.
Its not
Most surprising thing from this article is that svn’s reign was only two years. I vividly remember using it for much longer than that, but at the same time, adopting git almost as soon as it arrived.
It’s probably my memory playing tricks and svn was indeed a short term endeavor.
svn was absolutely in common use for a lot more than 2 years. I would totally believe that cvs was still in wider use though as there was sooo much legacy software hosted on it.
Reading this as someone in the process of migrating several projects to Fossil, interesting to see no mention of it all
A great article though!
My first contact was VMS with its versioning file system. Then RCS - before that we copied zip files around.
I was convinced that VMS's versioned files thing was DEC's cunning plan to sell more disk drive space (though I didn't and still don't know what the underlying mechanism was) - I was quite glad when I learned how to turn it off, though.
Uh? No SSCS? No VAX/CMS? No RCS? No DSEE? No ClearCase?
Fairly accurate in my experience.
Also a note about a specific bias from old-heads:
At the start things move much faster and changes are more impactful, but the start is ultimately much shorter than the rest of the lifecycle. That's why a lot of the stories you read about tech are about the early years (let's say 5-10 years, chronologically) and less so about the mature years (which can span 3+ decades, chronologically). So the early period has outsized visibility because it's cooler, I guess?
* * *
Using SCMs as an example:
SSCS - 1972. But at that point there was no internet and the number of computer users was minuscule. So SCCS is just a curiousity, a footnote, probably used by 0.000001% of Git users. So at this point for most practitioners SCMs basically don't exist.
RCS - 1982. See SCCS. SCMs still practically don't exist for most practitioners.
CVS - 1986. Now the internet is getting started and the number of computers in the world has increased by orders of magnitude. Even so, adoption of core development technologies like SCMs is slow and yes, it took CVS at least 10 years to become somewhat established. Even at this point, probably at least 50% of software developers still don't use SCMs (especially less professional ones). Visual Source Safe runs in parallel to CVS, with its own problems described in the article.
SVN - 2000. The internet is in full swing, computers are ubiquitous, things are really moving. It's super hard to evaluate how many developers still don't use SCMs, but the number is going down (maybe 30-40%?) and SVN is taking the world by storm. Even after the launch of Git in 2005, until at least 2009-2010, SVN had a solid shot at winning. It's tooling was much better, especially the GUIs, TortoiseSVN & co.
Git - 2005. Git is launched in roughly the same era as SVN, just towards the end. Once Github gets going it starts to take over the SCM scape, primarily from SVN, sometimes from CVS, Perforce, and also from non-SCM people.
So, if you look at the real dates implied above: CVS, SVN, Git are widely adopted in about a 10-12 year span (something like 1998-2000 to 2008-2010). Then we reach the current mature (monoculture?) stage where we're already at least 16 years in and it's quite likely this phase will last decades.
This story has happened for lots of tech. Many different PC OSes during the 1970-1980s, then basically only 3 since about 30 years - 1995 (Windows, MacOS, Linux).
Many CPU architectures during the 1970-1980s, then basically only 2 since about 30 years (x86, ARM - maaaaybe RISC-V).
Nice summary
More than technologies, what really evolved were the ideas on how to work and manage SCM systems. Things like atomic multi-file commits, using unified diffs, management by "patch queues" more than simply merging branches ad-hoc, and of course decentralized SCMs
Fossil deserves a chance compared to Git, even more in Rust times.
Where are my RCS people at?
The nostalgia hits hard.
I have a silly little wiki engine I made 20 years ago. It was an exercise in trying to better learn the traditional unix text processing tools. So the page templates were in m4, sed and awk did their traditional heavy lifting for request parsing and page generation. and page history was provided by rcs. Which fit better than cvs because it provides a history per file.
https://nl1.outband.net/fossil/gami/file?name=bin/save_node&...
The whole thing is really the mother of all injection vulnerabilities but I am still half tempted to try and spin it up once more and see what happens if i put it on the public web.
In a retirement home? /s
Where does that leave the SCCS people?
Killed themselves after using it for fifteen minutes. I used to have to teach a commercial "Intro to Unix" course which had a section on SCCS - shudder!
I've never actually used SCCS was it that bad? I'd have thought that alcoholism would have been enough to numb the pain.
> was it that bad?
I don't know - RCS just made more sense to me. And I really disliked RCS. You know some things are bad when something like CVS seems all warm and cuddly in comparison.
> I'd have thought that alcoholism would have been enough to numb the pain.
You may be right - it would certainly explain some aspects of my life since those days ;)
The slow-branch problem, where the team avoided branching because it took five minutes to create one and an afternoon to merge it.
I kind of "enjoyed" this aspect of CVS (for small teams, at least) since it strongly encouraged trunk based development.
Web design tip: don't have animations within a short distance of text, as human eyes evolved to follow the flashiest/fastest-moving thing around, which makes such text literally illegible to many of us. This particular site takes the cake in that regard by animating the whole page background.
The moving background detracts and distracts from the content making it hard to focus.
True, but the site is called Evil Genius Labs for a reason. And it's not too hard to switch off, there's a clear prompt in the bottom right corner. (Didn't try mobile.)
I turned everything off, but what's with the flashing ".ca" at the top of the page??