4 ms·

I started with SCCS, then moved to RCS, then to CVS for a long while. I'm now an occasional Git user. The number one problem with SCCS is a locked checkout par

I started with SCCS, then moved to RCS, then to CVS for a long while. I'm now an occasional Git user. The number one problem with SCCS is a locked checkout paradigm: one person gets to edit at a time. Also, it doesn't manage directories, only files. Read here for some alternatives: https://en.m.wikipedia.org/wiki/Comparison_of_version_control_software https://en.m.wikipedia.org/wiki/Comparison_of_version_contro...

masklinn 8y ago
> The number one problem with SCCS is a locked checkout paradigm That's common amongst the older breed of VCS: VSS or Perforce do the same. It's useful when working on binary files which can't be merged. Some centralised VCS (e.g. SVN) can be opted into locked checkout on a per-file basis. Definitely not a great default though.
- Arnt 8y ago
  It depends. I've worked with both SCCS, RCS, Perforce and git. The way SCCS and RCS did it was a pain, but Perforce's was IMO more feature than bug. When Perforce told me "uh, X is editing this file you're just about to edit", talking to X was usually a good idea for some reason I wasn't aware of. Sometimes X was working on one issue and I on another, and the deeper cause was actually the same. Sometimes X had forgotten to check in some work and would do so immediately when I asked. Not always. But often enough that I liked those locks. (Hated the RCS/SCCS locks though. Those had far too much cost and offered too little value.)
- agapon 8y ago
  p4 edit does not do that by default. But it can be done with explicit p4 lock.
- setquk 8y ago
  Sometimes locking out files on complex changes has a better outcome than a modify-merge cycle I have found. This doesn't scale out to lots of engineers however. If you're doing critical heavy lifting or refactoring, merging inline changes is hell.
  - mikeash 8y ago
    Every team I’ve worked with has had an informal locking method that gets used for really disruptive work. Instead of locking files in the VCS, you tell everybody that you’re going to be doing X, try not to make changes around that, and coordinate with that person if you really need to make changes on the same stuff. I think the informal technique works better since it’s a lot more flexible, but the basic concept is very useful.
    - setquk 8y ago
      That works until someone has a few beers at lunch and proceeds to come back and start smashing things (been there :)
- WalterGR 8y ago
  That's common amongst the older breed of VCS: VSS or Perforce do the same. For Perforce, that is false. For Visual SourceSafe, that behavior is the default, but can be changed.
- ahoka 8y ago
  Once upon a time I forgot to uncheckout a file in clearcase and went on a vacation...
  - WalterGR 8y ago
    Was the admin able to unblock your coworkers?
    - ahoka 8y ago
      The official process was so complicated that they just waited until I got back next week.
  - masonic 8y ago
    Couldn't an alternate config-spec work around that easily?
tragomaskhalos 8y ago
Here's what Verity Stob has to say about vcses of that era: "Thus the workflow was: connect to the archive, check out and lock a good selection of vital files, edit them a bit, then depart for two weeks in Corfu without releasing locks, secure in the knowledge that, short of guessing your password, any progress on the project by colleagues was effectively prevented. Marvellous.". :-)
smarks 8y ago
In the "old days" people were used to the locked checkout scheme, and we were afraid of merges. In a large code base most people were working on different files, so lock conflicts ("I want to edit a file but somebody else has it checked out") were fairly rare. We used SCCS on a shared filesystem. If you really needed to edit a file somebody else had locked, you simply removed the lock file. Of course, social convention was that you better have a really good reason for doing that. If you went on vacation with files locked, it was pretty much expected that your locks would be removed, and that you'd have to merge or otherwise deal with your stranded edits.

masklinn 8y ago

> The number one problem with SCCS is a locked checkout paradigm That's common amongst the older breed of VCS: VSS or Perforce do the same. It's useful when working on binary files which can't be merged. Some centralised VCS (e.g. SVN) can be opted into locked checkout on a per-file basis. Definitely not a great default though.

Arnt 8y ago
It depends. I've worked with both SCCS, RCS, Perforce and git. The way SCCS and RCS did it was a pain, but Perforce's was IMO more feature than bug. When Perforce told me "uh, X is editing this file you're just about to edit", talking to X was usually a good idea for some reason I wasn't aware of. Sometimes X was working on one issue and I on another, and the deeper cause was actually the same. Sometimes X had forgotten to check in some work and would do so immediately when I asked. Not always. But often enough that I liked those locks. (Hated the RCS/SCCS locks though. Those had far too much cost and offered too little value.)
agapon 8y ago
p4 edit does not do that by default. But it can be done with explicit p4 lock.
setquk 8y ago
Sometimes locking out files on complex changes has a better outcome than a modify-merge cycle I have found. This doesn't scale out to lots of engineers however. If you're doing critical heavy lifting or refactoring, merging inline changes is hell.
- mikeash 8y ago
  Every team I’ve worked with has had an informal locking method that gets used for really disruptive work. Instead of locking files in the VCS, you tell everybody that you’re going to be doing X, try not to make changes around that, and coordinate with that person if you really need to make changes on the same stuff. I think the informal technique works better since it’s a lot more flexible, but the basic concept is very useful.
  - setquk 8y ago
    That works until someone has a few beers at lunch and proceeds to come back and start smashing things (been there :)
WalterGR 8y ago
That's common amongst the older breed of VCS: VSS or Perforce do the same. For Perforce, that is false. For Visual SourceSafe, that behavior is the default, but can be changed.
ahoka 8y ago
Once upon a time I forgot to uncheckout a file in clearcase and went on a vacation...
- WalterGR 8y ago
  Was the admin able to unblock your coworkers?
  - ahoka 8y ago
    The official process was so complicated that they just waited until I got back next week.
- masonic 8y ago
  Couldn't an alternate config-spec work around that easily?

tragomaskhalos 8y ago

Here's what Verity Stob has to say about vcses of that era: "Thus the workflow was: connect to the archive, check out and lock a good selection of vital files, edit them a bit, then depart for two weeks in Corfu without releasing locks, secure in the knowledge that, short of guessing your password, any progress on the project by colleagues was effectively prevented. Marvellous.". :-)

smarks 8y ago

In the "old days" people were used to the locked checkout scheme, and we were afraid of merges. In a large code base most people were working on different files, so lock conflicts ("I want to edit a file but somebody else has it checked out") were fairly rare. We used SCCS on a shared filesystem. If you really needed to edit a file somebody else had locked, you simply removed the lock file. Of course, social convention was that you better have a really good reason for doing that. If you went on vacation with files locked, it was pretty much expected that your locks would be removed, and that you'd have to merge or otherwise deal with your stranded edits.