The evolution of Plastic SCM branches
A long time ago in a galaxy far, far away.... first level branches were the kings. If you weren’t a plastiker yet then keep on reading because the true story about the empire of selectors is about to be revealed.
All branches were born equal
When the first version of Plastic SCM was up and running (circa February 2006) all branches were “first level branches”. (If you’re interested on Plastic archeology check this
http://youtu.be/bn9vc7MRkSQ). There was one branch to “rule them all” which was called “the main branch” which still survives as the ruler of the entire Plastic universe.
The evil empire of selectors
All branches were created equal for a reason: you had your “main” branch, then you added content to it and later you were able to create a new empty “first level branch”. Then, based on selector rules, you were able to specify how to put content on it.
During this old period developers were forced to manually specify how the checkout process was going to happen. Look at the following selector:
repository “coolcode”
path “/”
branch “/task001” checkout “/task001”
path “/”
branch “/main” checkout “/task001”
Read through it in detail. What does it mean? There are two rules: the first one says: try to load the item from “/task001” and if you’ve loaded the item with this rule and you need to checkout, checkout to “/task001”.
Then there’s a second rule, which is the one performing the branching. This rule will only load items that were not loaded with the first rule (the selector rules are executed in priority order, top to bottom). So, at the beginning items will be on the “/main” branch only, so all will go through this rule.
If you check carefully you’ll see the second rule loads from “/main” but checkouts on “/task001”! This is how branching happened! On checkout, new revisions are placed on the new branch, then the first rule will be able to load them.
Child branches to the rescue
As you can see, all started with really dark days, when just checking out a file forced all poor programmers to remind that “selectors rule”.
Then child branches were born and the following selector:
repository “coolcode”
path “/”
branch “/main/task001” checkout “/main/task001”
Was equivalent to the previous one. So, only one rule was needed to specify the “branching behavior” defined before.
A branch like “/main/task001” means: “get the content from task001 but if it doesn’t exist take it from main and place all checkouts in main”. It was an important step ahead back in the day.
The age of smart branches
Later on (circa mid 2008) we launched “smart branches”. Basically to work on a branch you needed to “remember” the “starting point”. If “/main/task001” started from Label BL130 then you needed something like:
repository “coolcode”
path “/”
branch “/main/task001”
label “BL130”
checkout “/main/task001”
Otherwise “task001” would “inherit” from LAST on “main” which was the basis of the powerful “dynamic inheritance feature”.
Smart branches made things simpler because you were able to “set a base to a branch” and then your selector turned out to be something like the following:
repository “coolcode”
path “/”
smartbranch “/main/task001”
No need to specify the “label” nor the “checkout branch”.
Branching in 4.0
Branches in 4.0 inherit from “smart branches” but simplify the whole thing: a branch starts from a changesets and upon checkin, adds changes to its initial configuration on the new branch. And that’s all.
Basically, in 4.0 a branch that starts from changest 1024 (on “main”) can be named “main/importantfix” if you want to highlight it is a “child” of the “main” branch, but you can easily create “importantfix” directly from cset 1024 too and they’ll behave exactly the same.
We kept the “child branch” concept in 4.0 because we think it introduces a “branching namespace” which is very good for existing Plastic SCM users (used to it for years) and also good to organize development for newcomers.
But remember that now all branches are equal, independently of whether they’re children or “first level” branches, unlike what happened in Plastic prior to 4.0.
An image is worth…
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code.
You can reach me at
@psluaces.
3 comentarios: