Bondage And Discipline Version Control

Like a BondageAndDisciplineLanguage, BondageAndDisciplineVersionControl refers to tools and processes designed to prevent VersionControl mistakes by restricting the choices that users can make. Proponents consider the following to be desirable:

• Exclusive locking - Only one person can "check out" a file at a time to make changes to it. Others are prevented from working on the file until the lock is released.
• CodeFreeze - During periods just before a release, nobody can change anything unless given special permission to do so.
• Check-in Permissions - Only certain people are allowed to commit changes to the repository.
• Administrative Permissions - Only "administrators" are allowed to add new files, directories, branches, etc.
• CodeOwnership - There is a responsible party assigned to be the "owner" of each file, and changes to any file cannot be committed without the owner's blessing.
• ReviewBeforeCheckin

BondageAndDisciplineVersionControl is popular with those who are real serious about ConfigurationManagement. However, it is less popular with those who use AgileMethods due to its emphasis on process over progress.

I'd rather object to CodeOwnership being qualified under the derisive label of "bondage and discipline". In a lot of software development shops, it is more a matter of responsibility (there's one guy who takes responsibility in the correctness of one module) and collegiality. This is very far from "bondage and discipline".

It becomes BondageAndDiscipline when the version-control software enforces this property.

---

I don't see how CodeFreeze and ReviewBeforeCheckin are particularly bondage-y or unagile.

Because they're generally not necessary, particularly given good version control software.

[Neither have anything in particular to do with version control. CodeFreeze is usually practiced when there are distinct AcceptanceTests that have to be passed before a product is released. It doesn't make sense to continue changing the release candidate code while trying to complete this testing. (If you have good version control, you may be able to continue development on alternate branches, but CodeFreeze still applies to the release candidate.)]

[ReviewBeforeCheckin is simply an attempt to catch defects before they're picked up by other developers, thus saving everyone time. The fact that a version control system is used to share the changes is immaterial; you might just as well call it ReviewBeforeSharing? or ReviewToAvoidSharingDefects?.] -- DanMuller

Maybe, but from a BondageAndDisciplinePointOfView?, for some of us, used to be able to check in as we progress even if the code is not perfect (in our Local Repository using a DVCS), ReviewBeforeCheckin feels more like ReviewBeforeSaving?: Imagine if you IDE did not allow to save yor source doe change until it was perfect? Sounds like too much? well, ReviewBeforeCheckin is almost the same thing.

(Why did someone delete the comments above? -- DanMuller)

---

SCM products that apply BondageAndDisciplineVersionControl:

• SourceSafe.
• CccHarvest?.
• RCS.
• PvcsVersionControl
• TeamFoundationServer?
• ClearCase

---

ClearCase is in a class of its own for BondageAndDisciplineVersionControl, if you use dynamic views. In this case, your own workspace is an extension of the tool, which is installed as its own file system. You can't even edit a file without checking it out. And if configured wrong (or right, depending on your administrator), you instantly and invisibly get changes propagated to your workspace. I mean, I'm all for synchronizing often, but when your suite runs fine one minute and breaks the next without you touching anything, it's difficult to track down. --RobMandeville

---

Contrast with ExtremeVersionControl, DistributedVersionControl

---

CategoryVersioning