Here are the principles that I translated. Most of them are from Robert Martin's book Agile Software Development: Principles, Patterns, and Practices, but a couple of them are from The Pragmatic Programmers:
|Principles of Class Design
|The Single Responsibility Principle
|A class should have one, and only one, reason to change.
|The Open-Closed Principle
|A class should be open for extension (of its behavior) but closed against modification (of its contents).
|The Liskov Substitution Principle
|Derived classes must be substitutable for (require no more, and ensure no less than) their base classes.
|The Dependency Inversion Principle
|Depend on abstract interfaces, not on concrete details.
|The Interface Segregation Principle
|Make fine grained interfaces that are client specific.
| The Law Of Demeter
(Principle of Least Assumed Knowledge)
|Objects and their methods should assume as little as possible about the structure or properties of other objects (including its own subcomponents).
|The "Don't Repeat Yourself" Principle
|Every piece of knowledge should have one authoritative, unambiguous representation within the system.
|Principles of Package Design
|The Release Reuse Equivalency Principle
|The granule of reuse is the granule of release.
|The Common Closure Principle
|Classes that change together are packaged together.
|The Common Reuse Principle
|Classes that are used together are packaged together.
|Principles of Package Coupling
|The Acyclic Dependencies Principle
|The dependency graph of packages shall contain no cycles.
|The Stable Dependencies Principle
|Depend in the direction of stability.
|The Stable Abstractions Principle
|Abstractness increases with stability.
Here is what I ended-up translating them into. Note that some of the principles translated into more than one principle for version control because they applied to more than one of changes/workspaces, baselines, and codelines. I'm not real thrilled about the names & acronyms for several of them and am open to alternative names & acronyms:
|General Principles of Container-Based Versioning
|The Content Encapsulation Principle (CEP)
|All version-control knowledge should have a single authoritative, unambiguous representation within the system that is its "container. In all other contexts, the container should be referenced instead of duplicating or referencing its content.
|The Container-Based Dependency Principle (CBDP)
|Depend upon named containers, not upon their specific contents or context. More specifically, the contents of changes and workspaces should depend upon named configurations/codelines.
|The Identification Insulation Principle (IDIP)
|A unique name should not identify any parts of its context nor or of its related containers (parent, child or sibling) that are subject to evolutionary change.
|The Acyclic Dependencies Principle (ADP)
|The dependency graph of changes, configurations, and codelines should have no cycles.
|Principles of Task-Based Development
|The Single-Threaded Workspace Principle (STWP)
|A private workspace should be used for one and only one development change at a time.
|The Change Identification Principle (CHIP)
|A change should clearly correspond to one, and only one, development task.
|The Change Auditability Principle (CHAP)
|A change should be made auditably visible within its resulting configuration.
|The Change/Task Transaction Principle (CHTP)
|The granule of work is the transaction of change.
|Principles of Baseline Management
|The Baseline Integrity Principle (BLIP)
|A baseline's historical integrity must be preserved - it must always accurately correspond to what its content was at the time it was baselined.
|The Promotion Leveling Principle (PLP)
|Define fine-grained promotion-levels that are consumer/role-specific.
|The Integration/Promotion Principle (IPP)
|The scope of promotion is the unit of integration & baselining
|Principles of Codeline Management
|The Serial Commit Principle (SCP)
|A codeline, or workspace, should receive changes (commits/updates) to a component from only one source at a time.
|The Codeline Flow Principle (CLFP)
|A codeline's flow of value must be maintained - it should be open for evolution, but closed against disruption of the progress/collaboration of its users.
|The Codeline Integrity Principle (CLIP)
|Newly committed versions of a codeline should consistently be no less correct or complete than the previous version of the codeline.
|The Collaboration/Flow Integration Principle (CFLIP)
|The throughput of collaboration is the cumulative flow of integrated changes.
|The Incremental Integration Principle (IIP)
|Define frequent integration milestones that are client-valued.
|Principles of Branching & Merging
|The Codeline Nesting Principle (CLNP)
|Child codelines should merge and converge back to (and be shorter-lived than) their base/parent codeline.
|The Progressive-Synchronization Principle (PSP)
|Synchronizing change should flow in the direction of historical progress (from past to present, or from present to future): more conservative codelines should not sync-up with more progressive codelines; more progressive codelines should sync-up with more conservative codelines.
|The Codeline Branching Principle (CLBP)
|Create child branches for value-streams that cannot "go with the flow" of the parent.
|The Stable Promotion Principle (SPP)
|Changes and configurations should be promoted in the direction of increasing stability.
|The Stable History Principle (SHIP)
|A codeline should be as stable as it is "historical": The less evolved it is (and hence more mature/conservative), the more stable it must be.
You can read the 2nd article to see which version-control principles were derived from which OOD principles. Like I mentioned before, I'm not real thrilled about the names & acronyms for several of them and am open to alternative names & acronyms. So please share your feedback on that (or on any of the principles, and how they were "derived").