Suppose you don't separate changes in different branches, as it is usually done with many SCM tools. Then as developers complete tasks they integrate them into a branch. This can happen with the following scenarios:

• All developers use the same branch to make check-ins: we strongly advise against this way of working. Developers don't have versioning of their own work, besides this working way will have the problem we will introduce here. PlasticSCM can work on this way, but is not the best usage.
• Each developer has a branch to develop all his tasks. Developers enjoy versioning of their work but full isolation is not achieved.

The following image depicts the conflictive scenario. Suppose change 1 was submitted first, and then change 2 was created taking it as starting point. Later on change 2 is submitted and then change 3 goes through the same cycle.

What happens now if you discover that change 1, which implemented a difficult feature, has an important bug? You have another two modifications built upon it. So to fix the problem you would have to work on a fourth change, and submit it again. Besides, if you had to create a release for, let's say, a small demo just after submitting change 3, what could you do? What you have on your branch has an important bug so... You would have to try to fix the problem in a hurry or jus delay the demo.

Let's now solve the same scenario with branch per task. The picture shows the process.

During integration, if you have each change separated in a different branch, you can select which ones put into the release and which ones exclude, easily. Code on each change doesn't depend on the rest, so even if change 1 is broken you can still produce an stable release.