8 ms·
We used it. We knew no better. It was different then, you might not hear about alternatives unless you went looking for them. Source Safe was integrated with Vi
by codeulike 1y ago
We used it. We knew no better. It was different then, you might not hear about alternatives unless you went looking for them. Source Safe was integrated with Visual Studio so was an obvious choice for small teams.
Get this; if you wanted to change a file you had to check it out. It was then locked and no-one else could change it. Files were literally read only on your machine unless you checked them out. The 'one at a time please' approach to Source Control (the other approach being 'lets figure out how to merge this later')
- namdnay 1y agoI remember a big commercial SCM at the time that had this as an option, when you wanted to make sure you wouldn’t need to merge. Can’t remember what it was called, you could “sync to file system” a bit like dropbox and it required teams of full time admins to build releases and cut branches and stuff . Think it was bought by IBM?
- robin_reala 1y agoI guess you’re talking about Rational Rose? I had the misfortune of using that at my first industry job (fintech in 2004).
- meepmorp 1y agoRose is a UML modeling tool
- robin_reala 1y agoOops, it was ClearCase that was Rational’s SCM: https://en.wikipedia.org/wiki/IBM_DevOps_Code_ClearCase https://en.wikipedia.org/wiki/IBM_DevOps_Code_ClearCase
- becurious 1y agoClearCase?
- rswail 1y agoWhich is exactly how CVS (and its predecessors RCS and SCCS) worked. They were file based revision control, not repository based. SVN added folders like trunk/branches/tags that overlaid the file based versioning by basically creating copies of the files under each folder. Which is why branch creation/merging was such a complicated process, because if any of the files didn't merge, you had a half merged branch source and a half merged branch destination that you had to roll back.
- fanf2 1y agoCVS was called the “concurrent version system” because it did not lock files on checkout. Nor did svn. Perforce does.
- rswail 1y agoTrue dat, my mistake. That was its major feature, from memory though it still used the same reversed diff file format?
- ack_complete 1y agoPerforce does not lock files on checkout unless you have the file specifically configured to enforce exclusive locking in the file's metadata or depot typemap.
- School-Cotton 1y agoI am quite sure that you can edit files in an svn repo to your heart’s content regardless of whether anyone else is editing them on their machine at the same time.
- masklinn 1y agoYep, svn has a lock feature but it is opt-in per file (possibly filetype?) A pretty good tradeoff, because you can set it on complex structured files (e.g. PSDs and the like) to avoid the ballache of getting a conflict in an unmergeable file but it does not block code edition. And importantly anyone can steal locks by default. So a colleague forgetting to unlock and going on holidays does not require finding a repo admin.
- pjc50 1y agoThe lock approach is still used in IC design for some of the Cadence/Synopsis data files which are unmergable binaries. Not precisely sure of the details but I've heard it from other parts of the org.
- Disposal8433 1y agoThe file lock was a fun feature when a developer forgot to unlock it and went on holidays. Don't forget the black hole feature that made files randomly disappear for no reason. It may have been the worst piece of software I have ever used.