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

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

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

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.

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.

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.

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.

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.

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.

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!

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

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

Now it's different, we think our new tools are good, and we really mean it. But it's different.

What had you used that was better? CVS seemed like quite a step forward compared to RCS and the other available options.

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

QA was one guy doing manual testing with a checklist.

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.

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

In 2018

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.