4 ms·

We had one, highly specialized piece of software code which could only be checked out, worked on, and checked in by a single engineer at a time. You were only a

by sc68cal 15y ago

We had one, highly specialized piece of software code which could only be checked out, worked on, and checked in by a single engineer at a time. You were only allowed to touch this piece of code if you possessed a physical token. Ahh, the all powerful Source Control Shingle: http://thedailywtf.com/Articles/The-Source-Control-Shingle.aspx http://thedailywtf.com/Articles/The-Source-Control-Shingle.a...

matwood 15y ago
VSS did this with all files by default. Does that put VSS way ahead of its time? :)
- caseyboardman 15y ago
  No. God no.
- sc68cal 15y ago
  I'd actually take a Shingle over VSS. At least a shingle can't crash and corrupt all your revision metadata.
brown9-2 15y ago
This is really interesting and I would love to know what the code in question was responsible for. Requiring that work on it be done single-threaded like this suggests that some other part of the overall process broke down somewhere - the developers/automated tests/continuous integration server couldn't catch merge conflicts? Code reviews weren't done and made visible to everyone else on changes to this special code?
- sc68cal 15y ago
  Good question - though I don't think it's a problem of broken process, but an absence of processes like you listed above. That's when these types of "solutions" are devised/used.
  - marshray 15y ago
    Two things I've learned in my years as a developer: 1. Sometimes the best process is old fashioned communication between people with common sense. 2. Never underestimate the power of a rubber chicken.
    - sc68cal 15y ago
      >1. Sometimes the best process is old fashioned communication between people with common sense. I most wholeheartedly agree. Git, or a Source Control Shingle cannot replace effective communication. In fact, a solving a merge conflict is much more painful than a quick discussion.
- SoftwareMaven 15y ago
  Not necessarily. It could be a particularly tricky and critical piece of code that they want to ensure nobody is "auto-merging" into oblivion. By putting a mutex on it, you are forced to re-evaluate the state when you obtain the lock. You can't sneak in a change in front of somebody else's change, requiring them to re-evaluate (or, worse, merge and hope). If it was required for modules all over, it would be broken process. For a single module, I can understand it.

by sc68cal 15y ago

matwood 15y ago

VSS did this with all files by default. Does that put VSS way ahead of its time? :)

caseyboardman 15y ago
No. God no.
sc68cal 15y ago
I'd actually take a Shingle over VSS. At least a shingle can't crash and corrupt all your revision metadata.

brown9-2 15y ago

This is really interesting and I would love to know what the code in question was responsible for. Requiring that work on it be done single-threaded like this suggests that some other part of the overall process broke down somewhere - the developers/automated tests/continuous integration server couldn't catch merge conflicts? Code reviews weren't done and made visible to everyone else on changes to this special code?

sc68cal 15y ago
Good question - though I don't think it's a problem of broken process, but an absence of processes like you listed above. That's when these types of "solutions" are devised/used.
- marshray 15y ago
  Two things I've learned in my years as a developer: 1. Sometimes the best process is old fashioned communication between people with common sense. 2. Never underestimate the power of a rubber chicken.
  - sc68cal 15y ago
    >1. Sometimes the best process is old fashioned communication between people with common sense. I most wholeheartedly agree. Git, or a Source Control Shingle cannot replace effective communication. In fact, a solving a merge conflict is much more painful than a quick discussion.
SoftwareMaven 15y ago
Not necessarily. It could be a particularly tricky and critical piece of code that they want to ensure nobody is "auto-merging" into oblivion. By putting a mutex on it, you are forced to re-evaluate the state when you obtain the lock. You can't sneak in a change in front of somebody else's change, requiring them to re-evaluate (or, worse, merge and hope). If it was required for modules all over, it would be broken process. For a single module, I can understand it.