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