The definitive guide to "find"

Thursday, February 23, 2012 Pablo Santos 7 Comments

Motivation

We designed the “cm find” as a SCM query language able to solve almost any query in SQL-like format but avoiding direct queries to the underlying database system and hence avoiding difficult and long joins.
It has been there for years, and years, and years... but only the advanced plastikers knew about it... now is the time to open up the Pandora's box! :)
This post will help learning the possibilities of the “find” functionality which is available through the “cm find” command and also in the GUI through the “advanced” panel on most of the views.

What can you use “find” for?

“find” is great for scripting your own tools, but it is also great for customizing your UI with simple but very powerful queries.

The very basics

There are a few things to keep in mind when dealing with “find”:

Where are the fields? You can find all the “searchable” fields running “cm showfindcommands”

How can I format the output? If you’re on the CLI, you can format your output with –format=”{field} {field2}”

Useful “finds” to start with

Let’s go through some useful queries:

All the branches I created: cm find branch where owner=’pablo’

The first “trick”: cm find branch where owner=’me’. “me” will be replaced by the user invoking the query, quite useful as default configuration for some “views” in the GUI. Yo can try it from the “advanced” panel at the branches view as: find branch where owner=’me’

Another trick: doing it more “English like”: find branches where owner=’me’

Branches you created since the beginning of 2010: find branches where date >= ‘2010/01/01’

Finding all the branches you created with changes (important WITH changes) since the beginning of Feb 2012: find branches where owner='me' and changesets >='2012/02/01'. The field “changesets” does the trick. It actually hides a “join” (for the SQL guys out there) with the “changeset” table.

Let’s try again with “all the changes I created THIS month”: find branches where owner='me' and changesets >='this month'

Ok, now that you’re curious about what you can type on the “date” fields, here’s the entire list of available keywords: today, yesterday, "thisweek, "this week", "thismonth", "this month", "this year”, “this year","onedayago", "one day ago", "oneweekago", "one week ago", "onemonthago", "one month ago"

And now the ones to be used with a number like find branches where changesets >= “10 days ago”: "daysago", "days ago", "monthsago", "months ago", "yearsago", "years ago"
Enough for today! :)

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.

Setting up a Bamboo server to test task branches (a.k.a. feature branches)

Thursday, February 23, 2012 Luix Bamboo , integrations 0 Comments

Plastic SCM integrates with Atlassian's Bamboo for Continuous Integration. We implemented the Bamboo's plugin long time ago (3.0 supported it, about one year and a half if I recall correctly).

We use "branch per task" internally (more info about the task driven development here) which can blend perfectly with a slightly modified CI process (which in fact is considered by many as "the future of Continuous Integration").

As Codice's build master, I decided to adapt the Bamboo plugin for internal use, making it ready for "branch per task". My plan (combined with product strategy) is to start with Bamboo and then loop internally through Zutubi's Pulse, TeamCity from JetBrains and later Jenkins (aka Hudson).

Remove repository trigger

Wednesday, February 22, 2012 Ma Nu 0 Comments

We have been told that removing PlasticSCM repositories is very easy. Indeed, it's is.

But, come on!! who wants to remove its own production repositories!!! Ok, ok it can be a mistake.. let's prevent it.... Since the "rm" permission is too much generic (rm label, rm branch, rm changeset, rm item) we are creating a new bunch of permissions for PlasticSCM 4. But until it's released we can use our lovely triggers!!

First create the "rmrep" trigger, you can find the example trigger here. Create it as a "before-rmrep" in order to deny all the "rmrep" operations.

Now try to remove the repository...

You can't!! And you will receive an emergency alert to your mail!

Make sure you create the trigger as a "before-rmrep" trigger and the return value of the program it's not zero.

Enjoy!

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.

Working on a single branch- update-merge explained

Wednesday, February 22, 2012 Pablo Santos best practices , branching 0 Comments

While our recommended pattern is definitely “branch per task”, sometimes you’ll find yourself sharing a branch with another developer or even the whole team. This post will explain the two common situations and how Plastic SCM solves them.

Scenario 1- Working on the same branch without conflicts

Suppose you’re working on your branch, you check the branch explorer and you see your situation is like this:

You actually have some changes pending to be committed and you just continue working on them. Your changes are:

Meanwhile, another developer ends up with his changes that don’t collide with yours, and later decides to checkin:

Now you go and check your branch explorer and see that now you’re “behind the head” of the branch:

If you now try to check-in Plastic will warn you telling that you might have conflicts:

You can go and check the changes of this last cset and since you see they do not conflict with yours, you can just go to the root of your workspace and run an “update”.

Plastic SCM will detect that your changes do not collide with the new branch head and will be able to move you to the new head, downloading the new changes. You’ll be again synced with the head and ready to checkin without merge:

Scenario 2 – Synchronizing colliding changes

Let’s go back to the beginning: you’re working on your branch and modified the following files:

At the same time your colleague modified the following:

Ok, the two first files are colliding!

Your colleague now is faster than you and checkins his.

So now your workspace is behind.

You try to checkin and see again the “merge needed” dialog:

Please note that the merge-needed dialog brings you the option to start a new branch, which is really convenient!!

You can press “Ok” and merge, or you can try to update your workspace as you did before. Now, if you try to update the workspace, since there are colliding changes, the system will warn you:

And the following merge dialog will show up:

You finish your merge (hopefully you do not have tough conflicts to solve :P) and then go back to the branch explorer to check what happened:

You see there’s a “merge in progress” pointing from the head of the branch to the changeset you’re working on (calm down directed-acyclic-graph purists... this is just a way to show the merge in progress and most likely we will modify it to render the “in progress” changeset too!!)

Now you’re ready to checkin and once you do it you’ll get:

So you’ve created a “sub-branch” (branch within a branch) without even noticing it! :)

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.

Shelving (stashing) introduced

Monday, February 20, 2012 Pablo Santos branching , news 0 Comments

We had automatic shelving on versions 1 to 3.0 but it was removed in 4.0 due to the major underlying re-design and also time constraints.

Now we’re working to release 4.1 and it includes, among others, the new shelve system that blends the good things of the traditional shelving mechanism and the ability to “merge” shelves like some DVCS do (consider git stash).

This is the list of features of the new “shelve mechanism”:

Feature	Plastic SCM 4.1	TFS	Git	Perforce
Store temporary work in progress	Yes	Yes (shelve)	Yes (stash)	Yes (p4 shelve)
Apply temporary work to a different branch	Yes	No (can't merge, just copy)	Yes (stash)	Partial (you can later apply a "resolve")
Share shelves among developers	Yes	Yes	No	Yes
Share shelves among different servers (DVCS way)	Yes (using replica)	No (is not a DVCS)	No (can't share stash)	No (not a DVCS)

When is shelving useful?

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.

DVCS myths & facts

Friday, February 17, 2012 Pablo Santos distributed 4 Comments

Unless you’re not in the software industry or you’ve been down to Mars for the last 5 years, you’ve heard about DVCS. It stands for Distributed Version Control System and well, it is simply “the way to go in planet Earth for all programming related stuff”.

Admittedly I was more than happy today when I went to the SD Times front page and read: “Branching and merging: the road ahead for SCM”, which is cool considering “branching & merging” is the heart of our daily work.

This is our mantra!!

We always say “branching and merging is good”, we designed Plastic SCM from the ground up back in 2005 to help all the small and medium teams in companies out there moving towards parallel and later distributed development.

And now, certainly thanks to DVCS major players like Git and software heroes like Linus Torvalds, it became a major industry trend.

Version control used to be a commodity circa 2004, but 2005 rocked the SCM world and a new wave of tools tossed the foundations of the configuration management sector: big tools like PVCS and ClearCase and mass-oriented ones like Subversion started to vanish away.

And a brave new world emerged shaped to the form of the new development trends: agile, faster, more dynamic and fully distributed.

But, as usual, there’s confusion:

centralized minds making bold statements about what DVCS can and can’t do.

I’m trying to come up with a list in the purest Chuck Norris facts style about what’s true and what’s not true about DVCS. But, to start with, I’ll simply try to check whether 4 DVCS myths stated in the article in SDTimes are true.

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.

An arrow story

Saturday, February 04, 2012 Pablo Santos branch explorer 1 Comments

Well, a few weeks ago someone posted some comments from the Mercurial folks about our (and Git's) recursive merge strategy. I covered it a few days ago here.

Interestingly, some people argued that the way in which we render the branches in the branch explorer (merge links pointing from source to destination) is not correct. I really don't care about how correct it is since I don't feel like teaching graphs theory on a daily basis, but we do always listen :P.

This is basically how the Branch Explorer renders branches and commits (changesets):

And well, in Plastic SCM 4.1 (it is ready down here and soon will be published under "labs" for the impatient among you) there's a hacker hidden option:

edit branchexplorer.cfg

and add:

display.options.dag_mergelinks=true

and then you'll see:

Which, ok, well, whatever, I guess it has its own audience! :P

Vertical

4.1 features the long awaited, begged, proposed and requested "2D version tree feature" that I'm not unveiling today... :P And together with it it comes the possibility to render your branch explorer... vertically... up means newer.

All credits to Mr. Daniel Peñalba! :P

Enjoy!

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.

Migrating from SVN to PlasticSCM

Thursday, February 02, 2012 Ma Nu migration 0 Comments

Thanks to the script made by Ignacio Calvo (ignaciocalvo.com) you can migrate your subversion repository into PlasticSCM in a very easy way.

There are a lot of ways to do the same and with different tools, but this one is pretty and quite simple.

You can find the source code here, and a lot of more info in our public forum http://www.plasticscm.net

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.