3 ms·

Windows used to have a version control called Visual Source Safe. You'd have to select files you want to modify and check out them. Then they're locked. No one

by wg0 3y ago

Windows used to have a version control called Visual Source Safe. You'd have to select files you want to modify and check out them. Then they're locked. No one else in the team can touch them. God forbid you forgot to check them in at the end of the day and are not at work for a week then those files are locked and don't even have your changes. Yet to talk about branching. Better then that was svn which was no less horrible. So net result was that around 2000s, there was no concept and culture of version control for the windows developers. Pretty much. It was difficult to do, was cumbersome and such. Then came git. Offline, distributed, instant branching without creating a whole copy of the project and what not. It came from Linux but it's ease of use and feature set made it defacto in Linux world. But then came GitHub and that's when I guess most Windows Developers got to know about. True story, I joined a team in late 2000s and their workflow was to literally FTP the code daily to production. They all were on Windows and didn't know any better.

mindcrash 3y ago
First came Visual Sourcesafe, then came Team Foundation Server. Which was widely used in tons of Microsoft solution provider across the early .NET era. Git basically took off because of both Github and several major open source stacks gaining serious traction, even in the Microsoft solution space. In particular Node and several frontend focused stacks such as Bootstrap and Angular. If that didn't happen I do not think git would have ever made it into Team Foundation Server, which caused it to become the most popular VCS in the Microsoft ecosystem.
MissTake 3y ago
VSS… Oh the memories. Of dealing with corruption and other issues.
catlover76 3y ago
> Windows used to have a version control called Visual Source Safe. > You'd have to select files you want to modify and check out them. Then they're locked. No one else in the team can touch them. > God forbid you forgot to check them in at the end of the day and are not at work for a week then those files are locked and don't even have your changes. Holy shit, this is what lawyers still do--I always thought the developers who built the shitty enterprise software used by law firms knew this was garbage "version control", and wondered what they thought of it--but now you're telling me that the developers of that old dotcom era software themselves used a similar flow? for software engineering? insane
- Natsu 3y ago
  I had an employer who used MS-DOS + Novell Netware. Source was distributed with the application. If you needed changes, you had to pull the source file off the machine and send it to the developers. So the "same" application on different machines could have all kinds of minor differences. I hacked autoexec.bat to load the network and set some variables that identified each machine, then run another batch file stored on the network drive that did automatic weekly backups, copied new files back to individual machines on restart (without me having to run around with a floppy disk), etc. Once I got it set up, I did all further administration from my office, except the times I had to use the backups, in which case I would just xcopy all the files back onto the machine and run sys c: from my floppy disk.
  - catlover76 3y ago
    Nice lol
- EvanKnowles 3y ago
  We used to use a VCS called Borland (yeah, Delphi Borland) StarTeam, which was basically the exact same flow. Luckily for us they audited us at some point, decided we were using too many licences, and insisted we triple our monthly expense or stop using StarTeam - that was the incentive to persuade business to let us slow down dev for a bit while we changed to Git.
prepend 3y ago
SVN (and CVS) was way better than VSS. SVN was open source so there were multiple clients. And it was web based. And branching made sense. And you didn’t have to lock out files. And the VSS client was just really horrible and only worked on windows. SVN worked everywhere.
- bcrl 3y ago
  And Bitkeeper (that many of the concepts in git and mercurial came from) was better than SVN and CVS.
joshxyz 3y ago
thank you, i love stories like this. i've never touched mercurial, svn, etc yet i always fascinate on how git became preferred by the masses.
dreamcompiler 3y ago
> Then came git. Not quite. Then came Mercurial, which preceded git. Mercurial has the distributed VCS features of git but with a sane UI. And because it's just a Python program it runs anywhere. I think Mercurial lost because Linus either didn't know about it or didn't like it and wrote git in response to the Bitkeeper scandal. Then github came along and didn't support Mercurial, and that sealed Mercurial's fate.

by wg0 3y ago

mindcrash 3y ago

First came Visual Sourcesafe, then came Team Foundation Server. Which was widely used in tons of Microsoft solution provider across the early .NET era. Git basically took off because of both Github and several major open source stacks gaining serious traction, even in the Microsoft solution space. In particular Node and several frontend focused stacks such as Bootstrap and Angular. If that didn't happen I do not think git would have ever made it into Team Foundation Server, which caused it to become the most popular VCS in the Microsoft ecosystem.

MissTake 3y ago

VSS… Oh the memories. Of dealing with corruption and other issues.

catlover76 3y ago

> Windows used to have a version control called Visual Source Safe. > You'd have to select files you want to modify and check out them. Then they're locked. No one else in the team can touch them. > God forbid you forgot to check them in at the end of the day and are not at work for a week then those files are locked and don't even have your changes. Holy shit, this is what lawyers still do--I always thought the developers who built the shitty enterprise software used by law firms knew this was garbage "version control", and wondered what they thought of it--but now you're telling me that the developers of that old dotcom era software themselves used a similar flow? for software engineering? insane

Natsu 3y ago
I had an employer who used MS-DOS + Novell Netware. Source was distributed with the application. If you needed changes, you had to pull the source file off the machine and send it to the developers. So the "same" application on different machines could have all kinds of minor differences. I hacked autoexec.bat to load the network and set some variables that identified each machine, then run another batch file stored on the network drive that did automatic weekly backups, copied new files back to individual machines on restart (without me having to run around with a floppy disk), etc. Once I got it set up, I did all further administration from my office, except the times I had to use the backups, in which case I would just xcopy all the files back onto the machine and run sys c: from my floppy disk.
- catlover76 3y ago
  Nice lol
EvanKnowles 3y ago
We used to use a VCS called Borland (yeah, Delphi Borland) StarTeam, which was basically the exact same flow. Luckily for us they audited us at some point, decided we were using too many licences, and insisted we triple our monthly expense or stop using StarTeam - that was the incentive to persuade business to let us slow down dev for a bit while we changed to Git.

prepend 3y ago

SVN (and CVS) was way better than VSS. SVN was open source so there were multiple clients. And it was web based. And branching made sense. And you didn’t have to lock out files. And the VSS client was just really horrible and only worked on windows. SVN worked everywhere.

bcrl 3y ago
And Bitkeeper (that many of the concepts in git and mercurial came from) was better than SVN and CVS.

joshxyz 3y ago

thank you, i love stories like this. i've never touched mercurial, svn, etc yet i always fascinate on how git became preferred by the masses.

dreamcompiler 3y ago

> Then came git. Not quite. Then came Mercurial, which preceded git. Mercurial has the distributed VCS features of git but with a sane UI. And because it's just a Python program it runs anywhere. I think Mercurial lost because Linus either didn't know about it or didn't like it and wrote git in response to the Bitkeeper scandal. Then github came along and didn't support Mercurial, and that sealed Mercurial's fate.