4 ms·

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 p

by neilv 3y ago

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/ https://www.neilvandyke.org/linux-thinkpad-560e/".)

dudinax 3y ago
How do you commit to CVS when you're off the network?
- deleted 3y ago
  [deleted]
- whiplash451 3y ago
  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.
boffinAudio 3y ago
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.
the_duke 3y ago
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...
- piva00 3y ago
  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.
  - xorcist 3y ago
    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.
  - wdfx 3y ago
    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.
  - denton-scratch 3y ago
    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.
pjc50 3y ago
> 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.
Karellen 3y ago
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?
brabel 3y ago
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.
- actuallyalys 3y ago
  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-history,1368-2.html 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.
  - brabel 3y ago
    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.

by neilv 3y ago

dudinax 3y ago

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

deleted 3y ago
[deleted]
whiplash451 3y ago
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.

boffinAudio 3y ago

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.

the_duke 3y ago

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...

piva00 3y ago
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.
- xorcist 3y ago
  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.
- wdfx 3y ago
  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.
- denton-scratch 3y ago
  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.

pjc50 3y ago

> 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.

Karellen 3y ago

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?

brabel 3y ago

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.

actuallyalys 3y ago
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-history,1368-2.html 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.
- brabel 3y ago
  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.