[ferd]

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.

[layer8]

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

[ryandrake]

I briefly worked for a company as recently as 2010 that didn't use source control at all, and didn't even do the "copy source files and version their file names" practice. Whenever they had to cut a release for an angry customer, they'd just find an engineer whose local copy actually built successfully, bump the version number in the code, build on his workstation, and release that. CEO didn't want his software engineers doing anything but writing code, including setting up source control, tooling, automation, tests, documentation...

[vrighter]

this rings so painfully true for me. Except it was in 2008

[letitbeirie]

Devs who haven't worked in industrial controls won't believe it, but the overwhelming majority of critical OT software still doesn't.

[MisterTea]

Because the lunatics who wrote the software turned it into a stupid contraption where the source files are mummified in xml and entombed in a zip file or some other proprietary binary container. PLC coding standards should be taken out back one by one and shot twice in the head.

[LeifCarrotson]

As a Rockwell user, I can't agree more. But check out Copia Automation if you want to see an improvement to this problem.

[eru]

What's OT?

[letitbeirie]

Operational Technology.

It's basically IT but for industrial operations instead of commercial.

https://www.cisco.com/c/en/us/solutions/internet-of-things/w...

[eru]

Thanks a lot!

[pram]

Also production servers with /etc full of files appended with .bak, .bak.oct, .bak.incident, .bak.goddamnit2

[bravetraveler]

I spend way too much time thinking back on how many things like this I've left around

[EvanAnderson]

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

[Terr_]

Or possibly RCS, which was kinda-OK for config files.

https://en.m.wikipedia.org/wiki/Revision_Control_System

[siva7]

I remember these times. But diff tools were still used in the 90s even when no scm available?

[lasereyes136]

I see we worked at the same place.

[lasereyes136]

True story, I was around in the 1990s so I was aware of those practices. Really advanced people would have a scheduled job running every hour (or on some basis) to keep an old copy just in case it was needed, usually a zip or tar file. So, a really crude versioning system.

Fast forward to 2008 and I am working on a project where we had an older person working on the project that would do this, use a scheduler to create a zip version. The younger guys I worked with said it was a crazy system and didn't understand why someone would do that. I told him it was an advanced practice just 10 years ago. Basically, people did a lot of stuff that would seem crazy now given the tools we have now.

[ta1243]

> I told him it was an advanced practice just 10 years ago

This is a problem that can affect everyone, especially those working in more isolated areas. You come out with a great workflow in year X that's 5 years ahead of the industry, and it works, so you never progress.

Meanwhile the industry catches up, solving the problem another way, but you never learn because it's a step backwards, until it isn't, and then it's a massive learning curve.

You have to actively keep up with what the industry is doing and be willing to adopt the new ways of working even when they are in some ways a step backwards.

[eru]

Goldman Sachs set up continuous integration (with automated testing etc) back in the late 1990s / early 2000s for the eco-system of their in-house language 'Slang'. Great system, way ahead of its time. (The language was also pretty neat for its time. You can tell that the people who came up with had a Lisp background. Think of it as a worse version of today's Python. And probably on par or ahead of 1990s Python.)

In any case, because of when they built that Continuous Integration system, it was all jerry-rigged on top of CVS. Problem is, they were still using that system for Slang 15 years later.

[a_c]

The last I heard companies using the naming convention version XXXXXX.extension where each X is a feature flag was in 2023. Bringing source control into practice was an controversial ideas. No, I didn't work there

[m2mdas2]

Both of you are right. Right kind of right :).

[ta1243]

Young devs won't believe it but that is still the case today in parts of my company

[adamc]

I remember this. It pushed the team I was on to adopt CVS (this is before SVN).

[layer8]

Same. This was in 2003.

[eru]

Ha, that's still better than editing files directly on a shared drive.

[diamondo25]

My first job in 2012 was still working this way....

[electroly]

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

[lowercased]

If people knew about it, sure.

I was tasked with 'finishing up' someone else's work who was away on vacation. All his code was in sourcesafe... locked to just him. And he was away for another 9 days with no cell phone or email (not really a big thing in 1999) and... I was immediately getting pestering emails from the PM. "When is this getting finished? Ben said it was nearly done, just needed a few more bits.". There was pretty much nothing I could do. VSS was something he'd set up on a server that only he had a password to, and... no one had thought to have him to coordinate with anyone before he left on vacation for 2 weeks.

That was one of the first times I felt "everyone else just thinks we're interchangeable cogs". Possibly the first time. If one of the PMs took vacation, or one of the accounting folks, there was some defined handoff process "to keep things running smoothly". No one seemed to give a toss about "devs" in that case.

[sumtechguy]

SourceSafe 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]

I 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]

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

[rrix2]

when i was in high school i did an internship at a family friend's ASP.NET shop; we used VSS and I once got a call from an irate coworker who shouted me down for minutes for keeping a file locked after I wasn't using it until I started crying. I wasn't the one who had left the file locked this time; i'd done it in the past and he assumed it was my fault again.

sure do wish someone had checked those boxes for him!

sometimes it's still a surprise to me that I decided this is the career i still wanted to pursue after that experience but i haven't been shouted at like that since then.

[octopusRex]

We were a small team and loved visual source safe. I also wondered about his claim that he couldn't download a copy - yes, he was unaware you could allow multiple checkouts.

We were forced to migrate to SVN which I remember as being a pain compared to VSS.

The worst was our GIT migration. At the time it was not an easy Integration with visual studio. The process of migrating history was a challenge. We lost control of the process - suddenly GIT and corporate defined the process which for a small team was overkill and burdensome. The builds became laborious and time consuming.

This was years ago. I'm sure they've worked all that out now.

[eru]

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

I partially agree. But: one of the really nice things about distributed version control systems like git is that the guys running the servers can't make rules about what you are doing locally.

[edanm]

> It wasn't nearly as bad as people today make it out to be

This flies in the face of my personal experience (first 7 years in industry was before Git adoption), and also in the face of what most developers at the time said.

I mean, just look at Joel Spolsky, one of the most popular developer-bloggers, who also founded StackOverflow, Trello and other things. IIRC, he wrote a blog post calling the invention of DVCSs the most important innovation of the last decade of innovations, then he put his money where his mouth is by creating a new product specifically built around the idea of DVCSs. (Though he made a "bad bet" by focusing on Mercurial instead of git, IIRC.)

[marcosdumay]

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

[nox101]

visual studio's debugger is miles ahead of gdb and has been for 30 years

[ferd]

...package managers to (un)install software. RedHat Linux had RPM since 1998 at least

[BobbyTables2]

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

[eru]

Slight 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!

[SAI_Peregrinus]

With ephemeral NixOS, I'm reinstalling the whole OS (sort of) on every boot!

[dogleash]

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

[persnickety]

Umm, how to break it to you...

[Hunpeter]

I suspect you are joking, but bytes weren't always 8-bit long, were they?

[adamc]

I think the OP was being ironic.

[kurthr]

They were, if you were born in 1993?

[HWR_14]

Was this ironic? Bytes weren't always 8 bits.

[mikewarot]

Baudot enters the chat... 8)

[diamondo25]

12-bit words enter the chat

[hnfong]

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

[ferd]

CVS 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]

I 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]

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

[troupe]

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

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

[okr]

Hello Bitkeeper, hello Mercurial!

[somerandomqaguy]

That 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. ;)

[netule]

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

[corysama]

Even 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!

[demondemidi]

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

[tasty_freeze]

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

[BobbyTables2]

Seems to be that CI was also nonexistent then.

QA was one guy doing manual testing with a checklist.

[4ndrewl]

QA was the dev doing manual testing with one eye closed...

[onion2k]

Young devs won't believe it, but until the early 2000s...

...a lot of companies didn't use any form of source control at all. :)

[dimatura]

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

[jollyllama]

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

[syndicatedjelly]

I worked on a system with more or less this workflow…

In 2018