6 ms·

Order of my exposure to SCM Shared windows mount Visual Source Safe CVS SVN Perforce ClearCase Git Team Foundation Server Of those I still use

by mey 7y ago

Order of my exposure to SCM Shared windows mount Visual Source Safe CVS SVN Perforce ClearCase Git Team Foundation Server Of those I still use Git and SVN. Aside from the shared network drive, VSS and ClearCase are in a dead heat for the worst SCM I have been exposed to.

keithnoizu 7y ago
I feel blessed to have started with SVN and Source Depot (msft) and only come across CVS and Perforce on rare occasions.
- robaato 7y ago
  Source Depot == Perforce
- hyperrail 7y ago
  Source Depot is very similar to Perforce since sd started as a p4 fork. Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.
  - keithnoizu 7y ago
    Interesting. It wasn't a bad solution at the time, being able to pass around commits was nice and more straight forward than the patch mechanism on svn. Git and Mercurial were significantly superior solutions though.
gcoleman 7y ago
Visual Sorta-Safe, we used to call it.
- tres 7y ago
  Tell bob he needs to check in the file so I can work on it.
stevekemp 7y ago
Throw in SCCS, on SCO Unixware, and Darcs, and you match my exposure too, mostly. Now I remember what an abomination VSS was - with the mandatory locking behaviour.
- rejschaap 7y ago
  It wasn't mandatory, actually. It was possible to turn off the locking. But that was like entering a whole new world of pain. So most people didn't dare turn it off. They called it "multiple checkout", and the manual strongly recommended you do not turn it on. The software had issues with corruption due to operations not being atomic.
  - mey 7y ago
    The lack of atomic commits in VSS, CVS and ClearCase caused absolutely horrific problems, even on small teams.
    - silverbacknet 7y ago
      I remember when you basically had to yell "Committing!" and "Done committing!" to the whole room. Woe be unto those companies that tried to use VSS or CVS with more than a roomful of developers.
- marcosdumay 7y ago
  I can live with the locking behavior, but VSS had a tendency of corrupting the entire repo ever few weeks that is hard to accept.
  - flukus 7y ago
    I could live with the locking or the corrupted repos if it was half decent at just sharing code, but daily we had problems where someone would check in code, VSS would say it was checked in but the person updating would get stale versions. Sometimes if you looked at the server version it be be correct but not what you would receive on a fresh checkout. It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.

by mey 7y ago

keithnoizu 7y ago

I feel blessed to have started with SVN and Source Depot (msft) and only come across CVS and Perforce on rare occasions.

robaato 7y ago
Source Depot == Perforce
hyperrail 7y ago
Source Depot is very similar to Perforce since sd started as a p4 fork. Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.
- keithnoizu 7y ago
  Interesting. It wasn't a bad solution at the time, being able to pass around commits was nice and more straight forward than the patch mechanism on svn. Git and Mercurial were significantly superior solutions though.

gcoleman 7y ago

Visual Sorta-Safe, we used to call it.

tres 7y ago
Tell bob he needs to check in the file so I can work on it.

stevekemp 7y ago

Throw in SCCS, on SCO Unixware, and Darcs, and you match my exposure too, mostly. Now I remember what an abomination VSS was - with the mandatory locking behaviour.

rejschaap 7y ago
It wasn't mandatory, actually. It was possible to turn off the locking. But that was like entering a whole new world of pain. So most people didn't dare turn it off. They called it "multiple checkout", and the manual strongly recommended you do not turn it on. The software had issues with corruption due to operations not being atomic.
- mey 7y ago
  The lack of atomic commits in VSS, CVS and ClearCase caused absolutely horrific problems, even on small teams.
  - silverbacknet 7y ago
    I remember when you basically had to yell "Committing!" and "Done committing!" to the whole room. Woe be unto those companies that tried to use VSS or CVS with more than a roomful of developers.
marcosdumay 7y ago
I can live with the locking behavior, but VSS had a tendency of corrupting the entire repo ever few weeks that is hard to accept.
- flukus 7y ago
  I could live with the locking or the corrupted repos if it was half decent at just sharing code, but daily we had problems where someone would check in code, VSS would say it was checked in but the person updating would get stale versions. Sometimes if you looked at the server version it be be correct but not what you would receive on a fresh checkout. It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.