The task cycle in Plastic SCM

Create a new task branch.

It's really simple:

• Go to the Branch Explorer (you can achieve the same from the branches view).
• Select the parent branch (typically /main).
• Right click on it and select "create child branch".
• Enter the new branch name (related to the task, remember naming conventions), comment, and select the right base: the last stable baseline.
• ... And you're done!

The following figure shows the Branch Explorer and the main branch context menu.

Note that Plastic is able to keep track of branch hierarchies.  What's that mean?  It's all about the pattern we're following.  You make a branch for each task, right?  Well, each of these new child branches will be integrated back into its parent when you're finished.

It's very important that you give each branch a meaningful name, typically following a naming convention. In the example above, I named it task0142, which means it's the 142nd task in the associated issue tracking system.

You can see in the image above that I wrote a comment. It's not mandatory, but I do personally like to copy the task headline into the comment (something that can be automated with a trigger, by the way).

The most important part of this dialog box is the branch base, which means where the branch starts from. There are several options to define branch inheritance, but for the sake of simplicity we'll stick to the first one: select a well-known stable baseline as the basis for your task branches. In the case above, I selected Label and used Release_0.6.

Take a look at the Branch Explorer now to see what it looks like after creating your branch.

Work on your task

In order to work on your newly created task, just switch to it. You can do this from the Branch Explorer or the branches view. Just right-click on the branch and click on Switch workspace to this branch.

Your workspace will update and you'll be ready to start working.

From now on, just focus on your code. Make changes, check in often, and review your modifications. Remember, you can choose to work using the check-out, change, check-in mode or just the change and check-in one as described earlier.

After several commits your branch may look like the following:

Each circle inside a branch represents a changeset with drill down capabilities.

If you need to review what you've done on the branch, the diff options on the branch context menu will help you:

You can diff what you've done on the branch, compare with a given label, another branch, etc. You can also click on one of the squares inside the branch in the Branch Explorer (actual changesets) and check differences there too. It's a powerful tool you can use to see your progress between points A and B.

Work on the next task

Ok, so you're already done with your previous task, are you?

Well, then just repeat the cycle! Create a new branch, switch to it, make the changes, and you're done!

FAQ: Hey! But I don't have my latest changes on my new branch! Should I merge the old branch into the new one?

ANSWER: I see you're feeling the "merging instinct", but hold on a second. Is your new task related to the previous one? Are you sure? Most of the time, tasks are independent and don't need content from each other. In fact, that's why the branch-per-task pattern is so good. It keeps independent changes unlinked from each other until they get merged. Suppose your first task was a fix on an important database code -- an integral part of the application -- and the second one is just fixing a typo. You can feel free to integrate the second one, but maybe the first one won't make the cut for the next release. If both of them are on the same branch, then it won't be so easy to select which one you want.

Integrate the tasks back into the main branch

Now, let's merge the task branch you've been working on back into the main branch. The steps are very simple:

• Switch the workspace to the destination branch. Merging always works the same way in Plastic: you go to the destination branch and merge from the source. Pretty easy, huh?
• Select the source branch you want to merge. In this example, it's task0142. Right-click on Merge from this branch and the merge will start.
  
• Merge the files: The 3-way integrated merge tool will help you with solving the conflicts, if any.
• Once you've merged the files, they'll be kept in checked-out status in your workspace. This is how it looks in the Branch Explorer. You'll note that there is a pending merge link drawn:
  
  
  
• It is very important that you see and understand this. After a merge, you'll normally build your project. If it doesn't build or tests are broken or you find any other kind of issue, then you can undo the merge by un-checking out the files on your workspace (there are other ways to undo a merge, but this is the simplest one).
• To finalize the mergre (change it from pending to actual), remember to check in your checked-out files after a merge. Once you check everything in, you'll see the updated Branch Explorer with a merge link from the branch to the new changeset created as the result of the merge. The pending merge link is gone.
  

Reviewing changes

One of the big advantages of Plastic SCM is how easy it is to review changes. You can just double-click on a changeset and easily launch a diff describing what was modified.
The changes on entire branches can be also compared in the same way by right-clicking and selecting diff branch contents.

Once you launch the diff, you'll see the following window that lists the files modified on the changeset and details the changes made on each of them:

You'll easily be able to compare your code line-for-line for each of the changesets you've selected.  At a glance, you'll be able to see what changed and what was moved.  This is imperative when trying to pinpoint errors in the code.  No more searching through pages and pages of text to see where the problem might be -- Plastic finds all changes, and therefore all potential bugs -- for you.