Using first level branches in Plastic SCM – an strategic move

Thursday, May 31, 2012 Pablo Santos branching 0 Comments

It’s been a long road for first level branches in Plastic SCM but they’re reaching a renaissance after the 4.0 release.

I’m going to explain how main branches are useful and how we’ve designed the Branch Explorer to take advantage of them. Let’s go.

Strategy vs tactic

There are many types of branches (I strongly recommend getting familiar with this article and the excellent book on branching patterns by Steve Berczuk and Appleton) but for the sake of simplicity I’ll divide them into two groups:

Strategic branches: The ones shaping your development process in the long term. Samples are the “main branch”, release branches, maintenance branches, architecture branches, subproduct branches, and so on. They are normally few, but they’re long-lived and will be around for a while.

Tactical branches: The ones you use for short tasks. Typically task branches, bug fix branches, and feature branches. There are hundreds of these branches and they’re short-lived (maximum 16 hours if you stick to SCRUM, too).
But, of course, from the version control point of view “all branches are created equal” :).

So, my recommendation is the following:

Use “first level branches” for strategic branches: main, fix-3.0, hospital120, and so on

Use child branches for the tactical ones: /main/task1230, fix-3.0/fix3410

Visualization

This is how your Branch Explorer looks with all the branches floating around (this is, in fact, a small diagram!):

All those branches and no simple way to distinguish the “important ones” (strategic) from the everyday task branches.

That’s why we added “level filtering” to the GUI in 4.0:

This way, you can select which branching level you want to see… and this is how you can take advantage of the correct strategic/tactical split, rendering the whole thing correctly on the Branch Explorer. Suppose you just select “level 1”. This is what you'll see:

Now it is very easy to focus just on the “strategic” branches when you want to, understanding the overall project without delving into the details, and zooming into the tactical view when needed.

Conclusion

Before 4.0 we discouraged the use of first level branches except for hard-core hackers, but now they’re just like child branches (except for the namespace they’re on [parent/child] type of names). They can be created and used for lots of purposes, and using them for long-lived, strategic developments really is a good idea.

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.

Cherry pick vs merge

Sunday, May 27, 2012 Pablo Santos merging 3 Comments

We got an entry in the forum from a user asking several questions about merging and cherry-picking and I was about answering it when I realized the questions might be good for a wider audience, so here I’m writing a new blog post!

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.

New versioning schema

Tuesday, May 22, 2012 Pablo Santos news 0 Comments

Since we released Plastic SCM 4.1 a few weeks ago, we have introduced a new numbering schema. Our goal is to make it easier to understand especially concerning compatibility between client and servers.

The following picture explains what the 4 numbers we use to name a version (e.g. 4.1.10.279) means:

Major: The major version number (good for marketing and customers)

Minor: for identification purposes (4.0, 4.1, 4.2 and so on)

Common: identifies compatibility between client and server (inside the same major version!). It will be the number in commontypes. We are going to make it VISIBLE so customers understand when a version is compatible.

BuildNumber: just the number of the build -> it is a unique number that always grows and doesn’t mean anything… just how old and cool we get as we reach 200, 300, 500 or 1000!!! We keep it because it rocks

So, in order to understand if the new version you’re going to download is fully compatible with yours, check the following:

Go to your “about form” and check the 3rd number: is it the same as the third one in the version you’re about to download? Then the new version is fully compatible and you can update clients and servers separately, they’ll continue to run.

If they don’t match, it means you’ve to upgrade both clients and servers, since your current version and the new one are not compatible.

We try to minimize compatibility changes, but sometimes we’ve to make changes on the communication API and we break compatibility.

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.

Migrate from Mercurial

Tuesday, May 15, 2012 Ma Nu 0 Comments

Here it comes: A new entry about how to migrate your existing repository into Plastic SCM! This time, the unwitting subject of our inquiry is .... Mercurial!

Things we need:

• An Hg repository
• Git installed
• Plastic SCM

Hg-Fast-Export Tool

Download the hg-fast-export tool from HERE. This Python tool will allow us to migrate the Hg repository to a Git repository. Download and decompress the tool, then issue the following commands to migrate the repository into Git.

$ ...
$ mkdir hg_migrated_repository
$ cd hg_migrated_repository
$ git init
$ /path/to/hg-fast-export.sh -r /path/to/hg_repo
$ ...

I know this seems a bit roundabout, so let me explain. The hg-fast-export tool creates an import package that's in the old standard "inline" format. Plastic SCM does not support that format yet (though we plan on it soon!), instead opting to support Git's newer and more efficient import package format. Git is then the logical go-between to get from Hg to our very own Plastic SCM.

Import to Plastic SCM

As you know from previous blog posts, you only need to fast-export the Git repository and finally fast-import it into Plastic SCM. Here's a refresher:

$ ...
$ git fast-export --all -C --tag-of-filtered-object=drop --signed-tags=strip > repo.fe
$ cm fast-import myHgrepo@localhost:8087 repo.fe
$ ...

And that's all! Easy, right?

Manuel Lucio

I'm in charge of the Customer Support area.
I deal with complex setups, policies and working methodologies on a daily basis.
Prior to taking full responsibility of support, I worked as software engineer. I have been in charge of load testing for quite some time, so if you want to know how well Plastic compares to SVN or P4 under a really heavy load, I'm your guy.
I like to play with Arduino GPS devices, mountain biking and playing tennis.
You can find me hooked to my iPhone, skate-boarding or learning Korean... and also here @mrcatacroquer.

Want to switch from ClearCase, this is what Plastic has to offer

Friday, May 11, 2012 Pablo Santos migration 1 Comments

Okay, today instead of a deeply technical merging speech, I'll be on the "value proposition side".

Since I'd like to be as practical as possible, what I'm going to do is to copy, the reasons that one CC user sent me a few weeks ago. I think they're the best possible marketing speech.

Here it goes: We already use branch per task in ClearCase, and I see clear advantages in Plastic:

I think it is quite important to highlight that teams using ClearCase UCM tend to hate the whole thing, while it is taking longer for hard-core CC users to run away...

Let's now go through the main reasons to consider Plastic instead of CC:

No messy config specs anymore: (component selection is done via Xlinks, just work in the repo and branch at will)

Atomic commits (so no broken merges half way through)

Branch creation is lightweight, compared to CC, which is not as slow as others but not as fast as Plastic either

Can easily and quickly swap workspaces between branches

Branch explorer gives simple overview of where work is being done and makes merges much simpler to execute

Merges are much faster (as a side note, some of our biggest setups are merging thousands of files that used to last for... hours!)

Merges can be backed out (practically impossible with CC)

No complicated admin

Live backups

Support for multi-site with no added cost

You can install local servers for distributed development

Much faster to load a workspace (compared to CC snapshots – not as fast a CC dynamic views, which is instantaneous, but they're rubbish on Windows once you try to build)

Faster to checkin/checkout

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.

GUI improvements webinar

Friday, May 04, 2012 Ma Nu 0 Comments

Webinar date: 09/05/2012

As you may already know, the Plastic SCM 4.1 release has plenty of cool, new GUI features, like a search engine, Branch Explorer improvements, and the revamped History 2D view.

We’ve newly implemented an image preview in the Items view.  Some file types (like .txt files) work right out of the box, but others take a little ingenuity to set up.  But don’t worry; we’ll show you how!

We’ve also included lots of keyboard shortcuts to make your work life a little easier.  Tired of clicking through all the menu options to check out and check in your code?  We’ve got the solutions you’re looking for.

Sign up (and show up!) for our webinar to learn a few tricks!

Register now!

Manuel Lucio

I'm in charge of the Customer Support area.
I deal with complex setups, policies and working methodologies on a daily basis.
Prior to taking full responsibility of support, I worked as software engineer. I have been in charge of load testing for quite some time, so if you want to know how well Plastic compares to SVN or P4 under a really heavy load, I'm your guy.
I like to play with Arduino GPS devices, mountain biking and playing tennis.
You can find me hooked to my iPhone, skate-boarding or learning Korean... and also here @mrcatacroquer.