Friday, December 08, 2006

Configure your workspace (part I)

One of the main Plastic goals, as we already introduced in previous posts, is bringing really advanced features to any software development team.
And one of the most important features is the ability to configure the workspace.
What a workspace is? It is the place, at the developer's hard disk, where files and directories coming from a repository are stored. A repository (a database where all the versioned objects and their attributes are stored: file and directory revisions, branches, labels and so on) contains multiple versions for all the files and directories, but at a given moment in time, a developer will just take one revision of each of them. Those files and directories revisions will be downloaded to the workspace. Once placed at the workspace, the developer will use his prefered environment (from an IDE to a command line tool, depending on his preferences) to compile, test, write documentation, write code...
Well, now it should be clear what a workspace is (same concept as Subversion sandboxes, Clearcase views...), but, how would you exactly specify which revisions of which files should be downloaded from the repository? The answer is the selector.
Figure explains selector's mission: inside a repository many revisions are stored, and the selector is used to filter which ones should be downloaded. The sample shows the file foo.c having 3 revisions, but the developer just needs revision 0. The selector is responsible of telling the server that revision 0 is the one to be downloaded. And the same will happen to the other files on the figure. Clearly the selector provides a big flexibility to Plastic, being one of its more important core features, really making a difference with many other version control tools available.
The default selector for a workspace looks like:

repository "default"
path "/"
branch "/main"
checkout "/main"



What does it mean?

A selector is a set of rules that exaclty describe what must be downloaded to the workspace from the server, and also where checkouts should be placed. The default selector first rule is named repository and defines the repository to work with. During the first start up, the server will create a repository named default. That's why the first rule in the selector tells the system to use this default rep. So repository "default" means let's work with the "default" repository.
Once the repository is specified, a path must be defined. The path tells where the following rules will be applied. This means that different directories (and even files) could be downloaded applying different rules. This feature gives Plastic a huge power, but let's advance step by step.
By means of the path "/" rule, we are telling the system: whatever is inside the root directory on repository "default", apply the following rules.
And the following rules are: branch "/main" checkout "/main" meaning: take the last revisions from branch "/main" and if you have to make a check out, do it on "/main" too.
Why last on /main? Well, basically this is the default behaviour. If we don't want to take the last, we could take whatever is labelled with a certain label, or a given revision. The following selector would take whatever is labelled as BL0100.

repository "default"
path "/"
label "BL0100"
checkout "/main"

Just changing branch by label.
But it is also possible to tell the system to retrieve a given revision for a file or directory. Next selector will take revision 10 inside branch /main for the file /src/main.java, and the rest of items from the /main branch. The sample also explains how to compose several rules.

repository "default"
path "/src/main.java"
br "/main" revno "10"

path "/"
branch "/main"
checkout "/main"

Plastic evaluates rules one by one, from top to bottom.
If an item can't be downloaded using a rule, the next one will be applied, and so on, until it is downloaded or no other rule applies.
Ok, enough for a first approach to the power of selectors. There is still much more to explain but... it is more than enough to start... ;-)

0 comments: