On 18-Feb-2023 11:25:05:
As my twitter followers are already aware, I recently realized just how stupid Subversion's "tagging" behavior actually is. As someone who had never been forced to use CVS, I wasn't aware of what I was missing by not having real repository tagging. While goofing around with the various git web frontends, it finally dawned on me just how broken Subversion was. Let's take a little journey through some web frontends as a demonstration.
First off, this is a page most Subversion users will be familiar with. This is the commit log for a file as display by the popular frontend ViewVC. There isn't much more to say other than the top revision shown has a few tags made from it. (it is really hard to find a public repo with just the right amount of activity to make these screenshots)
Here is the git repository for git itself as displayed in the popular web frontend GitList. If you view a project on GitHub you would see a very similar interface. Coming from Subversion you wouldn't see anything wrong with this, GitList is a perfectly cromulent feature match for ViewVC's Subversion viewer. Of course, the reason you don't see anything wrong with this is because you've suffered brain damage from using Subversion too long.
This is a screenshot of CVSweb showing part of OpenBSD's repository. Notice how just by looking at the commit log, we can see where along the line each one of the tags was made? Because CVS has real repository tagging, it can easily connect each revision with the relevant tags. The CVS command line tools are more than happy to display this information as well, its not just a trick in the web frontend. The lack of this information in ViewVC isn't an oversight because ViewVC actually supports both Subversion and CVS and when it is used with CVS it display this information.
GitList on the other hand did simply leave it out, this is the exact same set of commits shown in the GitList image above but in the cgit repository viewer. Like CVS, git has real repository tags and the information is readily available at the command line by passing --decorate. Comparing cgit and GitList is what drew my attention to this. Of course, there is nothing wrong with GitList omitting this information, the git command line tools don't share it by default either. What drew my attention was that as an Subversion user I was completely unaware that this information was so easily available!
Subversion is effectively incapable of sharing information like this because Subversion does not have tags. Instead it simply has copies of directories that a team has agreed have special meanings based upon location. Doing some very basic operations on tags (like say show the commit log between two tags on the same branch) require you to jump through ridiculous hoops. People who have only experienced Subversion probably don't even realize how crippled they are by these "tags".
Subversion's atomic commit operations are definitely an improvement over CVS, but the fake tags are not as harmless as the Subversion manual leads you to believe. If you have only ever used Subversion, be warned that this unique "tag" behavior has likely warped your sense of what a VCS is capable of.
PS: Since inevitably someone will ask about Mercurial, as far as I am aware based on the hg documentation, it (like git and CVS) displays any tags associated with revision when viewing history. Finding a good public repo to use for a Subversion screenshot was hard enough, I didn't want to go try to find one for hg.
PPS: I made it my whole rant without bringing up the fact that Subversion "tags" are not read-only! (shit, nevermind)