
Version Control Before Git with CVS - chrizel
https://twobithistory.org/2018/07/07/cvs.html
======
jdblair
CVS was awful, but it was so much better than RCS, which operated only on
single files. There was a time in the late 90s when CVS + Bugzilla + Tinderbox
was the state of the art of CI if your toolset was all open source. I used
this combination at multiple workplaces 1998-2002. It worked and we shipped,
but we didn't really understand how bad the tools were.

At Sun all stuff was in Teamware, except when it wasn't, because every group
at Sun could do whatever they wanted to (we used SVN in the x86 ILOM team).
Teamware was good but suffered by being a wrapper on top of SCCS.

SVN was a revelation after CVS. I resisted switching to git from SVN for a
long time because the mental model for SVN is so much simpler: everything is
in one central place, every change is marked with a monotonically increasing
version number, remember a number and you can always reproduce the state of
the project. Eventually I saw the huge benefit of the "git workflow" (local
branches, pull requests) for collaboration. Branches in SVN are error prone
and always risked painful conflict resolution, so we made them rarely.

Perforce, which is commercial, was like stepping into another dimension (you
mean all this stuff just works? Out of the box?). There's another historical
timeline where Perforce has an early open-source model (like Redhat) and is
the dominant VCS.

I enjoyed that remembrance of 20 years working on free-software based
projects, not a bad way to start Sunday. I hope it was worth your time!

~~~
oblio
I still don’t like the Perforce model of workspaces or whatever they call it
(clients?). That mapping between the server folders and your local ones. Extra
complexity for no obvious benefit I could see.

~~~
vvanders
For the right use case workspaces are awesome.

We used to do code + art in the same 1TB perforce repo back when I did
gamedev. Art folder was ~600GB. Having a workspace to eliminate that as a
developer was awesome.

Git still fails to even approach the usefulness that P4 brought to those types
of shops. Between the auto-cache proxies, dealing with 1TB+ repos and
workspaces there's a reason P4 still does pretty well.

~~~
oblio
I won't reply to all the comments saying mostly the same thing, but Git
doesn't have this, true. SVN, another centralized system, does have it.
Shallow checkouts plus folder checkouts and you can have any combo you want.
Without adding another concept to take care of.

Much simpler conceptually, in my opinion.

------
adrianN
This article makes in seem like ancient history, but there are still projects
around that use CVS or very similar VCS like for example ClearCase. My
software engineering career started after git got popular, but I had to work
with ClearCase. I wouldn't wish it on anybody.

The inability to go back to old states of your project unless you happened to
tag them makes finding the cause of bugs extremely hard. I don't know how it
is in CVS, but in Clearcase you can tag only a subset of the files and what
you check out from the server is determined by a complex configuration file
("the configuration specification"). This is an additional hurdle to
reconstructing old states of your software because now you need to know the
config-spec to do so. Even if you have the old config spec, it might contain
fallback rules ("just take the latest version of the file") that effectively
make it impossible to reproduce the old state. Unless you're extremely
disciplined in your usage of the tool it's a real challenge to fix bugs for
old releases. And don't get me started on trying to backport bugfixes into
several old releases when branches are managed for each file separately.

This lack of a proper project wide history also makes it extremely challenging
to migrate to a different tool without losing a lot of information.

~~~
beefhash
Case in point: OpenBSD[1].

[1] [https://cvsweb.openbsd.org/cgi-
bin/cvsweb/](https://cvsweb.openbsd.org/cgi-bin/cvsweb/)

~~~
Freaky
And NetBSD:
[http://cvsweb.netbsd.org/bsdweb.cgi/](http://cvsweb.netbsd.org/bsdweb.cgi/)

------
foreigner
This is a really fun article. I started with CVS, graduated to Subversion, and
now to Git. It makes me really curious what the next paradigm shift will be!

The way I see it the evolution of these version control systems was driven by
the precipitously falling price of disk space.

CVS only stored a tiny bit of metadata locally so almost every operation
required contacting the server. That made using CVS very slow and branching
expensive.

Subversion stored a whole separate copy of every file locally. This made the
critical "show me just my local changes" operation an order of magnitude
faster and made branching cheap, at the expense of doubling the disk usage.

Git stores the entire history of everything locally (compressed). This makes
most operations an order of magnitude faster still, so much faster that some
things that were completely impractical with the earlier systems is now
routine, and branches are free.

What's coming next?

~~~
alkonaut
I hope pijul will gain traction soon: [https://pijul.org](https://pijul.org)

~~~
dilap
How's it scale w/ repo size? How about large binaries? Those are the biggest
pain points I have with git.

~~~
alkonaut
It's possible to check out partially without hacking, so should be in a better
place than git in that respect. Other than that I'm not sure if there is any
support (similar to LFS). It's also very much in its infancy so performance is
likely not a primary focus.

~~~
dilap
Hopefully not not a consideration, either, though. :-)

Definitely a very interesting project. Will have to play around with it a bit.

------
jon-wood
I guess I’ve become an old greybeard while I wasn’t paying attention. When I
started out in software development CVS, and later Subversion were the best we
had.

The emergence of git and GitHub have transformed Open Source development,
being able to just open a pull request or an issue and know you’ll get
notified when things happen is great - I’ve submitted patches for many things
which I just wouldn’t have bothered signing up to a mailing list to keep track
of in the past.

Signed, Github user 362 (from back before you could just sign up)

~~~
cimmanom
It also tells you how quickly software employment has exploded, that so many
(half? more?) developers have never used any version control (fundamental)
tool other than one that's been common for only a decade.

As recently as the first dot-com boom, Git didn't even exist. Even Subversion
was brand new, and it was mind-blowing how much easier it was to work with
than CVS.

One aspect of history that this article glosses over is that Git is not the
only or even the first third-generation version control tool created. The
earliest buzz I remember around DVCS was for darcs and bazaar, neither of
which I've heard mentioned since about 2009. Mercurial and Git were released
around the same time as one another, and were in a vim-emacs sort of grudge
match for a few years before Git became the clear winner.

Mercurial seems to still be in use in some odd corners of both the corporate
and open source worlds - probably a legacy of people choosing it for projects
during that period before Git "won". When I first tried it it felt a lot like
Subversion made distributed. Nowadays it feels incredibly clumsy next to Git.

~~~
muxator
That's not true, in my experience.

Mercurial has exactly the same features - and maybe something more - than git,
with a UX which is at least more consistent.

The main problem I see with mercurial is that its team stays too quiet:
everything is so smooth that probably nobody feels the need of doing much fuzz
about it.

The HN community has a high technical level, but during my career, out there
in the world, I have seen a lot of different folks: people that constitute the
bulk of the workforce often do not have a strong mastery of the tools they are
required to use. Sometimes they just endure them. For these people, using an
easier tool (and mercurial is a good candidate in my experience) could
probably help them to really improve their skills and become more productive
team members.

~~~
peatmoss
Back in the day, once I’d understood the value of decentralized revision
control, I was convinced Mercurial would prevail, and that Git would become a
footnote in history.

This is one moment in my past that was formative in helping me make good tech
predictions. Namely, if I see a technology that I think is better, and I think
it will win out over an inferior technology, I simply reverse my prediction
and enjoy being correct.

Coming from Subversion, Mercurial made so much more sense than Git. I still
think the CLI is more consistent. I keep hoping for a new shakeup in revision
control systems, though I suspect such a change will be a long time coming.

~~~
skinnymuch
Isn’t a big part of Git overwhelmingly “winning” is Linus making it? The same
sort of situation won’t be true in many other cases.

~~~
lsh
No, I don't think so. I think git "winning" was due to github.

~~~
kasey_junk
Specifically github made public repos free & private paid. Bitbucket did the
opposite...

------
cup-of-tea
I think one has to work a little without a tool to truly understand why the
tool has exists. Many new developers are forced to use git and they just don't
understand why they have to go through this painful process.

I started without version control. I very quickly realised that it's very easy
to break a project but forget how to undo your latest breaking changes. I
discovered subversion and it was amazing. It was 2006 and I was the only
person on my course to my knowledge who was using version control.

At around that time git came out and some people were trying it but many
people said it was completely unnecessary for most projects. I then tried to
use svn for a project with more than just myself as a developer and it was a
disaster. We had giant commits once a day that cause conflicts every time. It
was horrible. Git was truly amazing. I agree the cli isn't great (I use magit)
but you have to have lived without it to understand why it's so important.

~~~
gmueckl
SVN is one of the sanest and most robust VCSes there is. If even that leads to
disaster, then throwing git at the team will only make things worse. You need
to educate them about proper VCS use instead.

We've recently transitioned to git at work and a couple of weeks later I'm
already stuck in a week-long repository cleanup project on one of the central
repositories because people just created a phenomenally huge mess in it. They
were experienced and happy SVN users before, but somehow the boss forced the
git hype train on us and has to pay the price now.

~~~
jogjayr
Having worked in both git and SVN shops, SVN is adequate as a server-side VCS.
Most of the time you don't need branches on the server side. However, using
only SVN client-side is absolute misery - no interactive rebasing, local
commits, local branches, stashing, or committing specific lines from a file.
You absolutely have to use something like git-svn or hg-svn to be productive.

The other (and this is a major one) downside of adopting SVN for your org is
the dearth of decent tools for code review and collaboration. At a previous
company we used Fisheye/Crucible which is seriously not fit for purpose. At
another SVN shop I worked at, we emailed patches to each other (seriously).
And the lack of quality tooling is down to SVN's declining popularity -
there's no market.

~~~
gmueckl
The lack of good tooling for SVN is because git is so utterly inadequate at
doing it's job. So this created a need for a ton of tools that pave over those
flaws and now the resulting ecosystem is a money making machine.

~~~
jogjayr
You're saying git is so bad that an ecosystem sprung up to support it? But if
it's so bad why would it have a large enough userbase to support that
ecosystem? That logic seems backwards.

~~~
gmueckl
The initial users came because of an enormous hype fueled by "Linus made a
VCS" and a weird quasi-religious belief in the community that it is better
than anything else in that space. Crazy times back then, really.

------
Pete_D
> When people talk about Git being a “distributed” system, this is primarily
> the difference they mean. In CVS, you can’t make commits locally. A commit
> is a submission of code to the central repository, so it’s not something you
> can do without a connection.

Not just commits - log, diff, status, almost everything I can remember needed
to go off to the remote repository for information. Not only was this annoying
when you didn't have connectivity, it was slow when you did.

I do occasionally miss the ability to version files individually though.

~~~
pimlottc
Subversion, for all its improvements, was the same way. I remember jumping
through a lot of ssh proxytunnel hoops just to be able to check svn history
when I was working at a remote customer site in 2006.

The first time I ran “git commit” and it finished almost immediately blew my
mind.

~~~
pjmlp
On the other hand, Subversion will be quickly done before a git clone is
finished.

~~~
philwelch
If you clone more often than you commit, Subversion is the VCS for you :)

------
_jsdw
I wonder whether something like pijul ([https://pijul.org](https://pijul.org))
might represent the next step forwards; I am no expert in these things but the
patch based approach it takes sounds interesting and potentially very
intuitive to work with. I might have to actually give it a go one of these
days!

~~~
dralley
I feel bad for thinking that it's a terrible name, since it's probably a fine
name in some other language, and I don't want to be an entitled American
English speaker expecting literally everything software related to be in
English.

And yet, it's a great tool that I suspect that it will never get traction for
precisely that reason. The abundance of options enables people to be shallow
enough that a silly-sounding name knocks it out of consideration.

~~~
methyl
What's wrong with this name?

~~~
jedieaston
As an english speaker, I don’t know how to pronounce it. Git, subversion,
sourcesafe, they can all be easily pronounced.

------
simula67
What would version control look like after Git ?

Git famously was not built for monorepo [1]

I would like to see sub-tree checkouts, sub-tree history, storing giant asset
files in repo ( without the git-lfs hack ), more consistent commands, some
sort of API where compilers and build systems can integrate into revision
control etc

[1]
[https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be...](https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&t=2595)

~~~
mmphosis
WWgitND, or “What Would git Not Do.

------
notaplumber
"Opening the Source Repository with Anonymous CVS." Usenix 1999, by Charles D.
Cranor (AT&T), Theo de Raadt (OpenBSD).

[https://www.openbsd.org/papers/anoncvs-
paper.pdf](https://www.openbsd.org/papers/anoncvs-paper.pdf)

[https://www.openbsd.org/papers/anoncvs-
slides.ps](https://www.openbsd.org/papers/anoncvs-slides.ps)

OpenBSDs involvement here is conveniently missing, arguably GitHub may not
have ever existed.

Also of note, despite the paper being presented in 1999, AnonCVS was operating
as early as 1995. Other projects were still putting tarballs on FTP, no read
access to source history.

------
angry_octet
Others having mentioned the terror that was Clear Case, but I just want to
highlight one of its bad features: everything was stored in a relational DB.
And consistency was not guaranteed, so at one point all the code was
corrupted. After recovery from the backup, it was retired with vengence, and
everything went back to RCS and CVS.

When I wanted everyone to switch to Git or Mercurial (~2007) the main
questions were about branch merges (MUCH easier in git than CVS) and the
reliability of the version storage.

Many have now moved back to a centralised model of control (github), even if
they have many partial copies. The incredibly RDBMS (non-git) method of
managing the meta-data of github systems is very disappointing, but not
surprising. If github is 4th gen, then I'm hoping for 5th gen, where all SE
meta data is also available as a replicated database, which you can spin up
with a local httpd.

~~~
ptman
You mean like fossil [https://fossil-scm.org/](https://fossil-scm.org/) ?

~~~
angry_octet
While there are nice features in fossil (and sqlite is fantastic), but it is
not git compatible. If the code and artifacts were kept in git underneath then
exchanging code with other repos would be seamless. I don't understand why
they rejected keeping tickets as files in a version control system (separate
from the code), instead of blobs. It just seems unfriendly to manipulation by
other tools. Philosophically, I like that git can be extended with small tools
and modules instead of a monolithic executable.

------
tootie
My first professional coding job used SourceSafe which was lock-based so you
couldn't even do concurrent versioning. Everyone had to take turns with the
files.

~~~
reitanqild
Perforce was like that when I used it. (> 2009)

Why people liked it or even tolerated it still puzzles me.

Edit: While I'm sure this was what I experienced it might be because of
configuration by the organization I worked for, but I doubt it as I remember
reading everything I could find about Perforce since I disliked it so much and
wanted to find out why everyone seemed to like it.

~~~
dhd415
Perforce has supported concurrent versioning since at least 2001 if not
earlier. Individual files could be marked as requiring locks which is useful
for binary files for which concurrent changes cannot be merged (one of the big
reasons why Perforce is so popular in game development), but it's not either
the default or only option. It sounds like your organization had severely
misconfigured Perforce.

------
mooreds
I started my software engineer using CVS. I was using CVS as recently as 2014.

Why? Two reasons. I'd played with git but hadn't really understood the power
of trivial branching (though I was one of those CVS power users who could
branch, but tended to use my IDE to manage it). I remember thinking to myself,
oh this is like CVS, because that is how I used it when I played with it.

The bigger reason is that I was managing a team of 2-4 developers that rarely
worked on the same thing. We all worked in the same room. The codebase was
relatively small (35k loc). I could see no good reason to make the change when
CVS was "good enough". I was the same reason we used the same old crufty bug
tracker--too many features to write to spend time upgrading infrastructure.
Unless it was a 2x efficacy improvement; we did add automated testing and
scripting around deploys because the benefits were obvious.

Now I love git and the power to branch and stage commits but I am still not
sure it's needed for colocated teams of that size.

~~~
btrettel
I'll second your suggestion that centralized version control systems have
advantages for small projects. I use SVN for most of my personal projects,
because no one else is contributing. (Only one branch. In fact, I have never
branched in SVN.) The simplicity is a major benefit.

The main downside is how condescending some Git users can be to SVN users.
When I mention I use SVN, I often hear nonsense like "Oh, you must not
understand tree structures." Actually, I do, and I see that they have no
benefit for certain things I'm working on.

The one thing I'd like is the ability to commit without an internet
connection, which distributed systems can easily do. But this hasn't been
enough of an issue to motivate a switch.

~~~
peatmoss
SVN also maintains one killer advantage over git to this day: Storing large
binary files.

\- Data scientists and researchers who want to check in the original products
of data collection, cleanup, etc.

\- Software with large artistic assests like audio, textures, and other visual
art.

I think about the reproducible research movement and think to myself that SVN
is strictly better for many such projects.

~~~
adrianmsmith
And Subversion, being centralized, allows you to opt-in to a "lock, change,
commit" workflow, on a file-per-file basis, or on basis of file-type. Which is
great for binary files, as pretty much any binary file such as Excel sheets or
Photoshop documents or even PNG assets can't be easily merged, so Git's "work
independently, then merge later" workflow can never work with those files.

------
perlgeek
I didn't have much contact with CVS, but I used SVN quite a bit. Things I
remember from these days:

* There was no separation between commit and push. How weird.

* "svn log" or "svn blame" would take ages, because it had to tal to the server.

* Well-run larger projects had branching guides, because the built-in commands didn't track enough meta data to do merges safely later on

* SVN made it trivial to checkout only a subdirectory of a bigger repository (which I still sometimes miss in git), so people often tracked different projects in separate directories of one repository.

The only thing I remember about CVS was that to clone something from CVS, you
had to know some root directory (this presumably was the webroot), and
sourceforge.net didn't show available webroots -- so there were tons of
technically "open source" repositories that you still couldn't clone, because
the webroot wasn't documented.

~~~
opk
With cvs, specify just "." and it will checkout all the modules in the CVS
repository. That would include CVSROOT which was the module containing hooks.
But, yes it was sometimes annoying that the module name wasn't clearly
documented.

------
jedberg
I enjoyed skipping the part of the article that explains how CVS worked,
because I lived it. :)

CVS at the time felt like an amazing upgrade to RCS, just like Git feels like
an amazing upgrade to CVS.

I wonder though, have we reached the end? If there anything beyond Git? When I
used RCS, I would always lament "it would be nice if two of us could work on a
file at the same time". When I was using CVS, I'd lament, "It would be nice if
two of us could work on a group of files at the same time and merge our
changes".

But using Git, my only lament is, "I wish this were easier for new developers"
and "it would be great if there were a standard workflow". Problem one has
been somewhat solved by GitHub/GitLab, and problem two has been solved by some
pretty standard git-flow tools. Neither one really demands a new paradigm in
VCS though.

~~~
jpeloquin
> Have we reached the end? If there anything beyond Git?

The ability to split and merge repositories as easily as we can split and
merge branches might open up some new use patterns.

The particular context I'm thinking of is scientific repositories. These tend
to grow in size and scope in an unplanned manner. Pieces inevitably need to be
split off for a collaboration, to be made public, or because someone is
changing institutions and needs to take part of the project with them.

------
e40
I remember importing all our RCS files into our first CVS repository, around
1991. It was back when CVS was primarily used for maintenance of SunOS. As a
result, this is the first commit in the repo I spend most of my time in:

    
    
        commit 0d92e7f51fa3e1dd3d2257e9900e7ea0b37d96de
        Author: jkf <jkf>
        Date:   Mon Oct 21 07:53:43 1985 +0000
    
            Initial revision
    

RCS migrated to CVS which migrated to git.

------
peterwwillis
RCS was okay if you were a sysadmin, terrible for everyone else. CVS was okay,
but still limited. SVN was more advanced, but buggy as hell. Git is more
advanced and less buggy, but over-complicated and unintuitive.

Git was actually started in order to complete core functionality and let
someone else make the front-end for the VCS. But somewhere along the line
people just decided they didn't need a user friendly frontend, and now the
core is what people use every day. 13 years later and it's still difficult to
use. Unless someone comes up with a really slick universal frontend for it,
it's probably time for a new VCS.

~~~
cpdt
What about Mercurial?

~~~
peterwwillis
Good question. I never gave it a fair shot, and it used to have some flaws,
but maybe it's cleaned those up by now.

------
gkya
A CVS lifesaver that you can put into your shell init file:

    
    
      export CVS_RSH=ssh
    

This defaults to rsh and figuring out that I had to set it like this took me a
shameful amount of time (mostly because it produces such and unhelpful error
message). I literally couldn't pull the OpenBSD src tree for months...

I'm one of the few people who deliberately learned and used CVS (for a while)
in recent times. I did not have any public repositories at the time and needed
VCS for my configuration and some documents (Org mode mostly), and the model
where I could have a central repository on a local directory which I could
easily back up was compelling. Then I figured out a filesystem layout where I
could back up all my work easily and this became useless, thus I switched to
Mercurial. Nowadays I'm considering going just git, because it's what
everybody uses, and Magit is a compelling piece of software.

I use RCS regularly along with Mercurial and Git nowadays. RCS is good for
e.g. when I have a tree where most of the content is pdf files (papers),
images, and other binary data that does not really need to be version
controlled, together with an Org mode files for notes. I also have a pool of
Elisp files which contain the personal bits of my Emacs configuration, and I
use RCS on them because their histories are not related to one another. It's
no good for projects anymore because it is essentialy a tool used when people
used a single computer to develop software to which they connected w/
terminals, so they were all users of the same machine and the code was always
in a determined location.

One thing people tend to confuse with CVS or SVN is that they think it's a
client/server model whereas it's actually a repo/checkout model. The repo is
central and can totally reside in a local tree, and checkins from different
checkouts go directly to that repo. This is akin to sharing one .git tree
between all your checkouts of a single repository.

------
kyberias
> Did you passive-aggressively rewrite a coworker’s poorly implemented
> function out of cathartic necessity, never intending for him to know? Too
> bad, he now thinks you’re a dick.

When did it start to be like this? Making code better is a dick move now? Who
rewrites stuff passive-aggressively? What does that even mean?

------
craigsmansion
Nice article but the conclusion doesn't really follow from how the article is
build up.

> It illustrates well why understanding the history of software development
> can be so beneficial—picking up and re-examining obsolete tools will teach
> you volumes about the why behind the tools we use today.

As the article re-examines this obsolete version management tool, it becomes
clear it's pretty easy and straightforward and can do a lot of things that git
can to a certain degree. On top of that it's dead-easy to setup and use, in
fact, its simplicity might be an indication that's it's not all that obsolete
and might be exactly the right fit for new small personal projects.

~~~
bronson
Those are some really optimistic takeaways. I hope you'll try CVS and report
back (especially a merge, or looking at project history including deleted
files). I don't think any of these statements will stand up to scrutiny.

~~~
craigsmansion
I am using CVS (and even RCS) and for small personal projects, it's perfect.
Maybe there are problems with merges or project history in a larger context,
but as things are, at the end of the day, I type the single command `cvs
commit' and have a magic backup with revision history as a bonus. Sometimes
that's all a project needs.

------
jbgreer
I see a couple of other references so I know I'm not unique, but my first
experience of version control was SCCS on SCO Xenix. Then RCS, CVS, SVN and
Git. I never used Perforce or ClearCase. Knew some folks who used PVCS and
StarTeam and Visual SourceSafe.

I played with Bazaar, Monotone, Mercurial and Darcs but not enough to really
appreciate them.

As an aside, I met Larry McVoy at a Linux convention in 1999 and heard him
speak about BitKeeper. Those were interesting times.

------
mathewsanders
My first job in the US ~2011 was in design team at monster.com.

One of the engineers had made a SVN repository for all our design specs and
had cooked up a simple intranet page where the latest version of a design
could always be shared by a permanent URL but also a history of all earlier
versions.

That was my first experience with version control and I remember thinking it
was magic. I never found out who made that, so if you’re reading thanks for
going the extra mile :)

------
gregmac
Though I had experience with cvs and subversion mostly through open source
(mostly in sourceforge), I remember installing Trac around the time it first
came out, and using that as equivalent to what would be done with GitHub
today. Of course you had to have one install of it per project (or per
'organization', depending on your repository setup), and run it on a server
somewhere.

Trac was great though, especially for the time: subversion server, source and
changeset browser, tickets, wiki, roadmap. Aside from my own personal stuff, I
switched several open source projects to it, and got a couple companies on to
it. It quickly became to me an essential part of the dev stack, and was a
great way to get the full dev stack* up and running relatively quickly.

* Other than continuous integration, but for me that came later. I worked on a lot of php stuff that could be deployed from source and never really saw the need then. Now I think it's essential and don't work without it.

------
jancsika
> If cvs commit is what you were used to, then I’m sure staging and pushing
> changes would strike you as a pointless chore.

But using only `cvs commit` would be the equivalent of using a single script
with git that adds every single thing in the relevant dirs and then blindly
commits it.

In other words, the people coming from cvs and svn and complaining that git
added a step for them were either doing an impeccable job of keeping their
source dirs clean _at all times_ , or they were implicitly admitting that they
weren't keeping track of what they were adding to their own repos.

I would guess there are old projects that fit the latter description. But I
know from experience there are old projects that clearly fit the latter.

~~~
perlgeek
At least with svn it was best practice to run `svn diff` before committing,
just like `git add -p` is considered a better practice than `git commit -a`.

SVN also allowed you to commit only specific files, so if your working
directory wasn't clean, you could mostly still commit just the parts you
wanted to commit.

------
knorker
This post does not do justice to just how awful CVS is.

OpenBSD still uses it, and it's the main reason I've only rarely contributed
patches. CVS is just that crappy.

When I say it's awful I should admit that like FORTRAN it's not bad _for its
time_. But 1986 was 32 years ago. It's not bad because it's old, but it's not
32 years of good either.

Commodore 64 was great for its time, but I'm not going to load my version
control from a cassette player in 2018.

------
dreamcompiler
My temporal progression went CVS -> SVN -> Mercurial -> Git. Every one of
those was a major upgrade in functionality except the last. I never fought
against Mercurial, and I rarely needed to Google "how do you do X with
Mercurial" because it was so intuitive. But I spend about 30 minutes a day
fighting with or googling git. Git is a horrible mess, but I like everybody
else am forced to use it.

------
djhworld
My professional career started in 2008, but I didn't personally use Git/Github
until maybe 2010 or so, but it still took until 2015 for me to be able to use
Git/Github at work!

Version control system timeline for me has been

IBM ClearCase -> CVS -> Perforce -> SVN -> Git

The non linear path is from switching jobs/working on legacy projects, but
yeah.

Git has it's problems, especially on usability, but it's much better than all
the others in that list!

------
Ensorceled
While CVS may have originated with Grune, I think the CVS everybody is
actually familiar with is the version Brian Berliner wrote and maintained for
years.

------
kiallmacinnes
> So I invite you to come along with me on an exciting journey and spend the
> next ten minutes of your life learning about a piece of software nobody has
> used in the last decade.

I know of companies who only very recently moved from CVS, and I'd bet there
are many that still use it too..

Assertions like this are always dangerous, because inevitably, someone
somewhere is still using that tech you think is long dead ;)

------
ggm
RCS was god. I loved RCS. Firstly, unlike SCCS it was head state so fast (SCCS
recalced head from the history of change from base) Secondly, because it
wasn't CVS all that branch and remote crappe was irrelevant.

I never learned CVS. My peers at work hate me because I think branches are
something you prune off a rose bush in winter.

(I use git now)

------
MatthewWilkes
This is a really interesting perspective for people who haven't grown up with
Git. I'd not grokked a distinction between three generations of VCS before and
it's strange to me to hear git's bad UI described as something other people
think.

------
rukuu_001
Used CVS with my team for years, say what you like, it was rock solid on
branches.

I was appalled first time I had to pick apart a mess made by SVN on a branch.

I’ve made peace with git now, but struggled with the many different ways of
getting things done in git.

------
known
CVS served its purpose
[https://en.wikipedia.org/wiki/Comparison_of_version_control_...](https://en.wikipedia.org/wiki/Comparison_of_version_control_software)

------
silverlake
i work at a big bank that still uses CVS for most of their software. They use
SVN for "modern" projects, and only recently started dabbling in git. The
place is a tech museum.

------
gbroberts
YYMV. I once submitted a patch to OpenBSD without any prior knowledge of CVS
and found it easier than my first contact with GitHub.

Pure git without GitHub may be a little easier than CVS.

~~~
gmueckl
Pure git isn't easier than CVS. Git just adds complexity over CVS (in parts
just for the sake of being obtuse). CVS had its shortcomings, but complexity
wasn't one of them.

------
tedunangst
> Do you enjoy spending 40 minutes repeatedly running git rebase -i until your
> local commit history flows like the derivation of a mathematical proof?

Hells no.

~~~
dilap
I enjoy spending a couple minutes squashing, splitting, reordering and
tweaking commit messages in GitUp to make my commit history look nice.

I do wonder if it's pointless though. Not clear time spent on stuff like that
is really worth, vs how often you need to go back and check the history.

Maybe it's all just a exercise in OCD.

~~~
kenoyer130
Work on a code base with 40 plus developers and 30-40 commits a day. Having a
clean commit history is a must versus "test commit", "fixed that thing",
"added" etc.

------
cpeterso
In another timeline where git never existed:
[https://SVNHub.com/](https://SVNHub.com/)

------
yread
I miss bazaar a bit it felt like a saner git and moving to it from SVN and CVS
didn't require huge mindset changes

------
rajuljain883
I don't know why my company use perforce

~~~
JackCh
Probably because Perforce scales to truly massive monolithic repos while git
traditionally doesn't (the insanity going on at Microsoft notwithstanding.)

Personally I feel the best method is using lots of small repos, one for each
service or library, that get stitched together by the build system. I know
some large tech companies have created such systems and I have experience with
one of them working very well (they migrated from perforce). But this is a big
change from the monolithic repository model and institutional inertia is very
real.

(Perforce will eventually start to hit a wall when you get to the point where
money won't buy hardware big enough for Perforce to serve your repo fast, but
that's a very long way off for most organizations and I believe there are some
mitigations for it.)

~~~
jogjayr
> Personally I feel the best method is using lots of small repos, one for each
> service or library, that get stitched together by the build system.

But then your teams have to manage dependencies - or your release team has to
do it for them. It's very easy to run into diamond-dependency problems or
runtime classpath issues.

~~~
JackCh
Sure, but in practice it seems to work pretty well.

------
lokufda222
We still use CVS at work ... FML I need a new job!

~~~
bsder
Um, be glad your company uses _source control_.

------
Sir_Substance
>Did you passive-aggressively rewrite a coworker’s poorly implemented function
out of cathartic necessity, never intending for him to know? Too bad, he now
thinks you’re a dick.

Woof, I bet this guy's fun to have at standup.

~~~
alkonaut
I also don’t understand - is he _so_ used to git now that he thinks the idea
that working copy=staging area and commit=push are terrifying?

That’s the _normal behavior_ of most version control systems. Only a couple of
new distributed systems have separated staging and pushing.

Just forget about commits, there are only pushes.

