selector's future and product lines

As you may already know selectors are the core of the plastic system. When you start working on a branch right-clicking on the switch to branch menu, a selector is set behind the scenes.

The selector looks too complicated at the beginning, and that's why we've tried to hide a little bit with both smart branches, switch to branch and switch to label.

Advanced users get familiar with the selector and then start to get the best out of the multi-repository system, multi-server and so on.

But my main concern now is whether there is a way to make selectors easier to use for newcomers.

I was reading about Ruby for the last two weeks and I really liked how simple yet powerful it is.

What about writing selectors in Ruby? :-) I'm afraid it is not yet possible, but I'd like to make selectors easier to understand.

So my first approach was writing a better selector editor. I was talking to some plastic users about different approaches. One is creating some sort of wizard which would help users designing selectors. It is probably the best option but I still wanted to explore different alternatives.

The easiest one was keeping the code centric approach but getting some enhanced editor. And here you have a couple of early screenshots.



Ok, the only new thing you see here is the editor implement syntax highlight. Is not a huge step ahead, that's clear, but it helps.

The good thing is that it also features some sort of code completion for repositories, branches and labels.



Better? I guess it will make things a little easier.

But the magic language we defined for selectors is still too complicated.

Look at a default selector:

  repository "codice"
    path "/project/doc"
      branch "/main/doc"
      checkout "/main/doc"
    path "/"
      branch "/main/task001"
      checkout "/main/task001"

What does it mean?

Let's rewrite it with a different syntax (just adding some syntactic sugar)

   use repository "codice"
     if path starts with "/project/doc"
       download code from branch "/main/doc"
       check out at branch "/main/doc"
     
     if path starts with "/"
       download code from branch "/main/task001"
       check out at branch "/main/task001"

Better?

Is it maybe too verbose? If so you could skip some of the syntactic sugar or even jump into the current (and cryptic) syntax.

The good thing with the if based approach is that it is closer to code, which at the end of the day is what we're all used to, aren't we? Also, it clearly (I hope) shows that there is an important order in the selector rules. The system will try to load the first rule, otherwise the second one, and so on. It is not so clear with the current selector.

Instead of the download syntax there's a cleaner read/write approach submitted by Keith (a plastic power user!):

  use repository "codice"
   if path startswith "/project/doc"
     read from branch "/main/doc" //"from" is optional
     write to branch "/main/doc" //"to" is optional
   else if path startswith "/"
     readwrite branch "/main/task001" 

It can be even shorter (again more difficult for newcomers but ok for advanced users) replacing read by just r or rw for readwrite.

I think this new syntax makes things clearer.

But I still believe it is not enough.

A really good syntax will unveil even more possibilites. Let's look at the following:

  use repository "codice"
    if path starts with "/code"
      find revisions where 
        attribute='status' and 
        attrvalue='validated' and 
        branch = 'br:/main/task001'
    default
      readwrite branch "/main"

You could go even further!

You'd be able to define really complex queries in the selector. Remember that, at the end of the day, the selector is just a tree which means "this is what you've available to download into your workspace". If we find the right syntax, even code based, developers could write advanced selectors to map their repositories into their workspaces, really shaping the contents the way they want to.

Is there a reason? Why would you need to shape your repositories differently? Why would you need to create such variations?

Hey! Did I say variations? Yes, I did. Then, we could be entering the world of product lines. I first read about it long ago (check Greenfield & Short book on software factories) and since them I've been always worried about how to help dealing with product families using SCM. Of course multi-repository configurations help there (you can go to component oriented development) but it is not enough.

There are some papers on the subject, but I wonder if selectors are the way to go here.

Suppose you've some sort of central catalog where you store approved variations of different components. Then you could use the selector to actually set up a new project, selecting the right components and its versions. Components don't have to be constrained to files and directories under a same directory tree, but they could be spreaded through different trees, and be grouped together using, for instance, attributes, labels or some other mechanism.

Yes, it is still a long way to go but... we're doing our homework!