Committing code is easy with any version control system even integrating (merging) branches can be unless you're bound to some ancient tool.

Nowadays a very common modern practice with modern SCMs (ok, GIT can do it, Plastic can do it, and I guess that Mercurial can too) is to isolate each change (bugfix, new feature, new experiment, whatever...) on a new branch and then integrate them together on the main (or master for gitters) branch.

So, integration is easy, but what happens when you want to disintegrate a change?

In order to make the post more informative, I'll be explaining the process for both GIT and Plastic SCM.

Suppose I've made some changes on my codebase (I'll start working on a single branch to make things easier) so that it looks like the following:

I've made some changes on the changeset (commit) in the blue square third from the left, and then continued working.

I modified two files on commit 12 (the one in blue) and here are my changes:

And the second file:

And then modified the same files again to make the sample easier to follow on commit 13 as follows:

Well, I'd like to get rid of the changes on cset 12, but still keeping the ones at cset 13, which are good changes coming from a different fix.

How should I do that?

Disintegration (how I like to say it), subtractive merge (Clearcase parlance, and also the name of the command in Plastic) or revert (as GIT would say) comes to the rescue!

The image shows the current situation, and the commands to create a new commit removing (disintegrating or subtracting) the changes made on cset 12.

In GIT you'll use the revert command while in Plastic you'll use sm, short from subtractive merge.

Subtracting graphically

If you're using Plastic, you can easily subtract a changeset from the branch explorer or the changesets view.

It will launch the subtractive merge process, which will show you the elements to disintegrate:

If the merge is not automatic (not like the case I described above, which doesn't require any manual operation), the three way merge tool will show up, like in a regular manual merge process.

What's the result?

Well, as expected, just the changes on commit 12 will be removed.

Check how the added code in cset 12 is now removed, and the removed one (second file) is there again.

Plastic will create a link between the disintegrated revisions the same way it does after merging, but this time using a special subtractive merge link type which is drawn on red on the 3D version tree as shown below:

Working with branches

What happens when we're working with branches?

Consider the following situation where your team have been working on a couple of branches and then merged them back to the main branch.

If you take a look at the 3D tree of one of the items involved in the changeset, you'll see the following:

Which shows the merge arrows (green) from the two source revisions into the destination ones.

What if now you realize that task001 shouldn't go to the next release? You should get rid of it, using disintegration.

A new cset will be created as a result of the operation, and now your trunk is ready to be released, not including task001 changes anymore.

Conclusions

Modern SCMs will allow you run potentially complex operations such us subtractive merge, and as you've seen they're really helpful even on a daily basis, to revert mistakes or buggy tasks.

At Codice we focus on making this operations not only doable, but also as simple as possible, avoiding repetitive and error prone tasks, which doesn't mean you don't need to know what happens under the hood.