Hacker News Reader

Comment by neilv | Hacker News Reader

Good article, but I might be misunderstanding this one bit:

> These days, we are used to cloning an entire project on our computer, after which we can safely plug it off the network and continue writing software in a completely disconnected way. This simple paradigm was utterly and completely unthinkable 20 years ago.

I was doing this with CVS or SVN over 20 years ago. (For "https://www.neilvandyke.org/linux-thinkpad-560e/".)

View on HN

You can't commit locally with either CVS or SVN, if I remember correctly?

If the premise is "I can work on this locally", then you could do this since forever by just having a local directory...

You can't, and it was one of the major pain in the ass points allowing git and Mercurial to eat their lunches. Also developers "locking" entire subdirectories in SVN and blocking any others to merge into, bonus point when they forgot it and went on vacation.

Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell.

VSS, CVS and SVN were ok to use when there were no other choices, Perforce was really good but very expensive, git and hg felt like the future when they showed up.

Well, we should be a little fair to cvs and svn. The C in cvs stands for "concurrent" as in the absence of locks. That how they differed from competing products. Lockfiles existed, but were intended to be mostly informative as they could easily be forced by anyone with write access, and were intended for special situations.

The merge logic were pretty much identical for git and svn. The reason git is so much more advanced now is that is has improved a lot while svn doesn't see that much development anymore.

I agree that git and hg felt like the future, and bazaar and arcs before them, but mostly because they represented another workflow very different from other products, not because of some specific technical reason. Version control is a network effect and you don't see the gains until everyone agrees on a common workflow. The rest is an implementation detail. OpenBSD is famous for being a strong culture around their cvs for example and it works for them.

For the thankfully very short period that I ever used SVN, I remember it being massively painful if the network was down. The local processes would just hang and then your entire workspace was pretty much unusable. Couple this with a single-core 32bit machine and less than 1G RAM and you're pretty much stuffed for any sort of productivity.

VSS was awful if you had a high-latency link to the server. VSS used a very chatty protocol, and was impossibly slow over (say) a transatlantic frame-delay link. I had to update our local copy of the repo overnight; sometimes the update just failed, and my team was dead in the water for several hours.

A local SVN repository worked miles better. But house policy was VSS.

IIRC it wasn't just commits. You couldn't diff to previous versions offline either.

>Also developers "locking" entire subdirectories in SVN and blocking any others to merge into, bonus point when they forgot it and went on vacation.

Subversion?

I used subversion for an entire decade at one job and never ran into this, in fact, I did not even know it was possible in subversion.

When it happened with VSS before that we just got an admin to unlock the file(s) on the server.

>Merges in SVN and CVS were also very painful to do. After being bitten by it, every single place I worked at had to create protocols and guidelines on how often to merge/reconcile code to not waddle in a eventual merge hell.

I've just never had any issues with merging. shrug.

>VSS, CVS and SVN were ok to use when there were no other choices

I've used all three professionally and VSS never felt "okay" to use, it was very slow, super clunky, and prone to data loss and corruption. I would back up my files before commiting to VSS. You also just simply just can't view history of a folder if it was really big - the operation would just never complete. Basically, using VSS was just terrifying.

My first job was at HP in the late 90s and I remember that "the merge" was an event for which significant time was reserved. It was heavily planned. I don't recall the system we used, though.

You can't commit to a server, obviously, but you can commit to a local directory. You would have needed set one up in advance however. Checkouts are sparse, in git terminology.

Commit here approximates to a push in git terminology. The intended use is a little bit different. Normally you wouldn't have committed until you were really done with the work (and all reviews etc) since there is really no concept of a rebase. So a commit is really something you "commit" to. You work on the patch instead.

Some of the difference is from the tools, but some of this is also due to the difference between a patch based vcs and content addressable one.

How did you "commit locally" with Subversion twenty years ago? And if "local commits" were a thing, what was Svk for?

svk is a tool to do exactly this. You can always copy the actual repo, you have read access to it after all. Something like svk vastly simplifies this workflow and can keep your local copy up to date.

Keep in mind that the intended workflow with svn is to perfect a patch locally and commit when you are done. So something like svk is considered a special case, not an integral part of the workflow. git actively encourages you do split your work in separate commits using rebase.

So there is a big difference in intended use, perhaps not as much in technical ability. Linus would likely have gone mad had he forced his workflow on svn.

> These days, we are used to cloning an entire project on our computer, after which we can safely plug it off the network and continue writing software in a completely disconnected way. ... And guess what: your local repository also contains the full history of every single change ever made to your project

This feature also sets a hard limit on the size of your project, its files, and its history: it's limited to the smallest laptop of a developer.

Most of the time this doesn't matter, but alternative (often terrible) VCS still exist in industries where the files are much larger such as game development, video production, and chip design.

How do you commit to CVS when you're off the network?

I don’t think you can. But you can still work on your project and commit when you get back online.

Even 20 years ago, you could reasonably assume regular online connections.

Yeah, twenty years ago, it was quite important to already have everything onboard that you might possible need, when the modems didn't work.

I don't know what happened here, with this amnesia - twenty years ago, my CD stack was vital for some things - if only for finding code samples in the comp.lang.c archives that I long had on rotation in the multi-CD selector.

Thirty years ago, you had to have books. And magazines.

Fourty years ago, a guru friend.

I don't think any software that kept the full history of a repository locally would be usable 20 years ago, at all, simply because hard disks were measured in 100's of MB back then - just a few projects with full history could fill up the average disk.

I don’t think it would have been unusable. The first distributed version control systems are more than 20 years old. Plus, the size of hard drives was in the 10s of GBs [0] then and a lot of large projects have repositories that are a few GBs or less. [1]

So I think keeping the entire version history on a local hard drive was doable 20 years ago, but I think you’re ultimately right that keeping history locally would have been a less appealing solution.

[0]: https://www.tomshardware.com/reviews/15-years-of-hard-drive-...

[1]: This is just based on what I happen to have checked out locally, but it includes Rust and CPython.

This was a time that "cloud" was still a decade or so in the future for the huge majority of people. You had to keep all your data locally, including all your music and photos. There's no way anyone would want to keep full histories of their repositories locally, competing with their mp3s.

Did you have your own custom script for cloning an entire CVS repo?

I don't remember CVS having one out of the box, and just checking out a working copy via `pserver:` would leave you with a tree you couldn't even `diff` in a disconnected state IIRC.

...but also, if you create a local clone of the whole repo, and then commit a series of patches to it, how did you even manage to keep track of which ones weren't in upstream? I mean, keeping track of patches with the external `cvsps`/`quilt` tools wasn't monstrously difficult (even if it wasn't especially easy, either), but keeping track of which patch sets were in one repo but not another?

Reply on news.ycombinator.com