Show me the code!

When you are working on a development team, there are always situations in which you have to take a look into someone else's code. It can be something like an informal deskcheck to a formal code inspection (there is a great book about it: Peer Reviews in Software).
In previous posts I explained how Plastic SCM helps to isolate developers using branches. Isolation is essential to create the stability needed to work without interruptions (or achieving faster context switches and so on). But in today's topic I will introduce how Plastic can help creating better communication.
Then, we said you needed to share code with a team-mate so that he can have a look into it. How would you do it? There's a simple answer: he comes, sits at your desk and reads your code. Simple but... is it always the answer? Obviously not, maybe you want to work on something else while he looks at your code. So, there are a couple of options:
Option A: you make a zip file with your code, put it on a network drive so that your colleague can unpack it and start working on the code. Well, it is an option. But, what happens if he wants to make a change on the code while reviewing? Oops, copying files then turns out to be a bad idea, don't you think so? Aren't you supposed to have a version control exactly to help you on that? Why don't you use it for reviewing then? Maybe the answer is the following: depending on the SCM you're using, maybe having too many branches is not a good idea. If that's the case then programmers will be working in the following way: they make a check out, make changes, test them, check them in and it's done. So, check ins are done only when everything is perfectly finished but not before. Only from this moment on changes will be available for all the team members at the source control. But never before programmers check in code to the main line!! Meanwhile code will be only available at programmer's hard disk.
Ok, let's now go to option B. Wouldn't it be better to use the version control system to share the code for reviewing? Yes, but then you need an SCM capable of correctly handling branches. Plastic supports it. Indeed the natural way of working would be creating a branch for each developer, even for each task (Read the post about context switching).
Now if the programmer wants to get his code reviewed, he just has to check everything in to his branch.

Then, as the figure shows, the two programmers have their own workspaces, with their associated selectors to each of them. Selectors exaclty specify what has to be downloaded to the workspace, according to a given set of rules.
Assuming each developer has his own branch, first programmer will work on branch developerA and second programmer on developerB. First programmer's selector would be:

  rep "default"
    br "/main/developerA" label "baseline100"
    co "/main/developerA"

Quite simple: just set the same selector on his workspace, and that's it!! No zip-files involved... And if during reviewing he finds something he needs to change... no problem, he will just perform a check out and done.
Isn't easier? I think so, and more productive, less error prone... Lots of advantages... :-)