6 ms·
Young devs won't believe it, but until the early 2000s, most companies used source control systems that forced you to LOCK any file on a centralized repo before
by ferd 3y ago
Young devs won't believe it, but until the early 2000s, most companies used source control systems that forced you to LOCK any file on a centralized repo before you were allowed to modify it (MS's SourceSafe, ClearCase, Perforce)... This was often the case even if you just wanted to touch a file locally for some experimentation... insane.
So, at a customer site (while I was doing consulting for them), I couldn't stand it anymore (I had been using CVS myself since 1997). So I installed SVN to work on their project and showed it to the team. I was called an "irresponsible engineer"... "Modifying files without locking is a crazy! You don't do that on real engineering teams!"
The open-source world was at least 10 years ahead.
- hnfong 3y ago> The open-source world was at least 10 years ahead. I'm not sure it is the win you're suggesting. I had brief stints with CVS and TBH it really sucked. Luckily when I started coding seriously (which coincided with my first job), SVN just reached 1.0 and it was OK. This was 2004 already. IMHO, the whole situation was fixed only after Linus decided he had enough of the crap and wrote his own.
- troupe 3y ago> I'm not sure it is the win you're suggesting. I had brief stints with CVS and TBH it really sucked. What had you used that was better? CVS seemed like quite a step forward compared to RCS and the other available options.
- hnfong 3y agoThe point I was originally trying to make was that they all sucked before SVN came out. Especially when compared with the options we have now, I think it's slightly misleading to say OSS solutions were in any real way better back then...
- ferd 3y agoCVS certainly sucked by today's standards, and SVN was indeed a big improvement, and Git much more so. All I wanted to stress is that the "lock-before-you-can-touch" approach was the norm in the enterprise world at the time. IMHO, this fact alone made SVN (even CVS) better than all the commercial products which I used at the time. When some of the "enterprise" world started adopting SVN and commercial products started relaxing the locking mandate, the open-source world was already embarked on the decentralized model (git, darcs, arch, mercurial, etc).
- hermitdev 3y agoI used ClearCase quite a bit (and other (ir)Rational tools) at a previous job. It sucked pretty hard. But, it didn't _require_ you to lock files. It _strongly encouraged_ you to, and made working with hijacked files a pain in the ass, though. In practice, this is largely worked around with branches, though. And, branches from branches... Kind of mimicking the distributed workflow we know with git with more branches. But, yeah, ClearCase sucked pretty hard and was frustratingly slow. Also, too easy to miss adding files to source control and really annoying interface to _find_ view-private files. 0/10, would not use again unless I had a gun to my head.
- pmeunier 3y agoAt the time we thought our tools were good, and really meant it. Now it's different, we think our new tools are good, and we really mean it. But it's different.
- okr 3y agoHello Bitkeeper, hello Mercurial!
- onion2k 3y agoYoung devs won't believe it, but until the early 2000s... ...a lot of companies didn't use any form of source control at all. :)
- marcosdumay 3y agoThe open source world seems to always be decades ahead from "most companies" on every single dimension. Just look at all the craziness about being able to manage software dependencies by publishing different microservices versions, or all the emphasis on software testing without any other kind of correctness verification getting the spotlight. Oh, and those are the advanced companies out there. Most of them aren't even there yet.
- ferd 3y ago...package managers to (un)install software. RedHat Linux had RPM since 1998 at least
- BobbyTables2 3y agoWe’ve already come full circle. Nobody uninstalls packages from a Docker container… With immutable designs, we’re just reinstalling the whole OS on each update…just a bit more efficiently thanks to cheap storage.
- SAI_Peregrinus 3y agoWith ephemeral NixOS, I'm reinstalling the whole OS (sort of) on every boot!
- eru 3y agoSlight tangent: Back in the primordial olden days, people used to patch binaries. These days, we just compile them from scratch, when we want to make a change. So it's not too surprising that people apply the same approach to the whole OS installation. Mutation is hard to get right!
- nox101 3y agovisual studio's debugger is miles ahead of gdb and has been for 30 years
- BobbyTables2 3y agoSeems to be that CI was also nonexistent then. QA was one guy doing manual testing with a checklist.
- 4ndrewl 3y agoQA was the dev doing manual testing with one eye closed...
- jollyllama 3y agoPerforce is still in wide use today in certain types of organizations. In all the configurations I'm familiar with, one can unlock a file for modification but the only effect it has on others, is that they will see that you are modifying it in one of your workspaces.
- electroly 3y agoOld dev here--that SourceSafe behavior could be disabled entirely ("Allow multiple checkouts" in VSS admin), and you could undo other people's checkouts. It wasn't nearly as bad as people today make it out to be. The merge conflict UI was really nice, actually. Back then, as it is today, the bigger issue was the choices companies made in setting up their environments and the rules they set for their developers, rather than the shortcomings of the tool.
- sumtechguy 3y agoSourceSafe was rather nice with its integration too. Right from the GUI (amazing!). The downside to SourceSafe was its tendency to randomly corrupt things and then you get to deal with that for the rest of the day instead of working on things. Locking had some nice side effects. The devs talked to each other. Things where someone was getting in the way all the time showed where the code needed to be abstracted better. In practice it was not that big of a deal (all in 1995).
- SoftTalker 3y agoI worked on a project that used SourceSafe for several years. Never recall any corruption. What was really different from today though is that most developers did NOT run the application locally or in an individual environment. They all worked together in a common dev environment. It was either too difficult or impossible to run copies of the application locally. So that is why file locking was used. You had an entire team of developers simultaneously working on the same set of files.
- sumtechguy 3y agoThat was not my exp at all. We ran out of our local source dir. Think my manager would have had a fit if the checkout failed to build on his machine. We tried to keep our dev machines as close to what an end user was going to end up with and keep all the devs in sync with each other. So if an issue came up you could have a few people look at it. You could also 'break the lock' locally then fix it up later (though this was discouraged). It also kind of forced you to make sure what you checked in built. As you would have 5 other devs coming over to ask why you broke the build. It was a manual process. Most of that sort of thing is handled by CI/CD type systems now. You can break the build on your branch. But no merging up of that junk... We used a rudimentary CI/CD to enforce 'always builds and runs'. Someone wrote a bit of script that would check it out at 5PM and kick the build on a 'blessed' machine. If that failed the people who checked it in were on point to fix it the next morning. It was not better or worse. It was just different and more manual. Manual though means steps get forgotten or skipped.
- layer8 3y agoYoung devs won't believe it, but in the late 1990s, quite a number of software companies didn’t use source control at all. You just copied source files from/to a central location, and from time to time made a version_x.y.z copy of the source directory.
- pram 3y agoAlso production servers with /etc full of files appended with .bak, .bak.oct, .bak.incident, .bak.goddamnit2
- bravetraveler 3y agoI spend way too much time thinking back on how many things like this I've left around
- EvanAnderson 3y agoYou may be the only one. I wish the vendors I deal with spent even a nanosecond thinking about leaving stuff like that around. (Let alone multi-gigabyte copies of production databases, long-since obsoleted patches, etc.)
- siva7 3y agoI remember these times. But diff tools were still used in the 90s even when no scm available?
- Terr_ 3y agoOr possibly RCS, which was kinda-OK for config files. https://en.m.wikipedia.org/wiki/Revision_Control_System https://en.m.wikipedia.org/wiki/Revision_Control_System
- lasereyes136 3y agoI see we worked at the same place.
- letitbeirie 3y ago
- dogleash 3y ago> Young devs won't believe it Sure they would. They believe anything. I made up some nonsense one day that bytes weren't always 8 bits and they believed that shit.
- Hunpeter 3y agoI suspect you are joking, but bytes weren't always 8-bit long, were they?
- persnickety 3y agoUmm, how to break it to you...
- HWR_14 3y agoWas this ironic? Bytes weren't always 8 bits.
- AlgorithmicTime 3y ago[dead]
- mikewarot 3y agoBaudot enters the chat... 8)
- diamondo25 3y ago12-bit words enter the chat
- tasty_freeze 3y agoI've been using perforce continuously since 2000. It is rare to lock files. The only case I'm aware of are things that are binary blobs to perforce, eg, if you open a windows .doc file to edit it. But 99.9% of the time I'm operating on text files of one kind or another and perforce doesn't lock it; it is the usual merge and then sync/resolve if anyone has changed the file since you opened it.
- demondemidi 3y agoI was at Intel in the late 80's through the 90's. We used RCS for chip design (storing IHDL and validation test suites), and SourceSafe for any group writing windows device drivers (MASM 6.1 anybody?). You reminded me of locking the centralized repo, I completely forgot about the headaches that caused! I'm now recalling how painful source safe was. I wonder if trauma caused me to forget. Eventually everything migrated to SVN as part of the Linux migration, including windows desktop revision control. I was so used to the SVN/CVS patterns that I strongly resisted git later on after I'd left. I'd say it took me a good two years of grumbling before I finally opened my mind to git, and in hindsight it's brilliant. The biggest thing that I had trouble letting go of was having a monotonically increasing version number of the repo. That felt ... safe. I mean, now you just have to be liberal with tags. I agree with the OP, git couldn't work 20 years ago on desktops because drive sizes were too small. Sure it could work on distributed computing, but AFS drives were slow, and NFS quotas were teensy. Git only worked because drive sizes exploded.
- somerandomqaguy 3y agoThat wasn't the best bit. Try having having someone in the organization leave without checking back in his or her code before they left. Guess who's IT department is getting a phone call to manually break the locks. ;)
- corysama 3y agoEven better: You could set your system clock to a future date, check in some code, roll your clock back, and leave the company. Version Control Time Bomb!
- netule 3y agoOr the guy who really just needs it: "Hey, Alex. I saw you've head BasePage.aspx locked since last month. Mind if I work on it for a bit?" "I still need it." "Any idea when you'll be done with it?" "No." This is what the waterfall model was made for.
- syndicatedjelly 3y agoI worked on a system with more or less this workflow… In 2018
- dimatura 3y agoIn the late 2000s I worked at a lab that used subversion, which I also found annoying after getting used to git. My hack was to use git-svn - it let you locally use git, and eventually sync your work back to svn. Worked like a charm. The rest of the lab soon got sold on git afterwards, though.