The new branch explorer and Mono 1.9.1

We've just tried the latest mono release with the newest branch explorer (BL102, featuring smart branch support and some redesigned elements) on Linux.



It rocks! Doesn't it?

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!

New smart branches preview is out

Smart branches change the way branching is used in plastic. They make it simpler to choose the starting points where you want to start working, display the status of a single branch and dealing with multi-level branch configurations.
A couple of weeks ago we released our first preview, and today we're releasing the second one.
What's new in BL102?
Basically the branch diagram has been improved (again) to support full zooming, draw labels in a different way (after receiving user's feedback) and also renders parent links which are actually the links showing which baseline, branch or changeset acts as the ancestor of a branch.
Take a look at two new screenshots below:

The last one shows how the zoom works after the last changes.

If you want to try the BL102 release check the following link:
http://www.codicesoftware.com/releases/PlasticSCM-professional-2.0.102.0-windows-installer.exe

Plastic smart branches are out!

I’m very proud to announce the first release of smart branch support in Plastic. The release is still not official (so don’t use it for production before contacting us) and it can be directly downloaded here, no registration needed.



What are smart branches exactly? They’re the evolution of Plastic basic branching functionality answering some common users’ demands: they can remember their starting points so that when you switch back to a branch you don’t have to remember it yourself. While this is very good for a number of well-known branching patterns, it will really help our branch per task practitioners when they have to recover old branches.

A smart branch is, conceptually, very close to a stream, but we preferred to stick to the more traditional name of branch instead.

With smart branches Plastic remembers which one is the starting point of a branch at any given point in time. The branch properties dialog (also new in the BL101 release) will show you which one is the current starting point of the branch and will also let you modify it creating a new one (which is very helpful during rebase operations, for instance).

The new properties dialog also lets users modify the branch name and specially its comments, which was something customers were asking for since 2.0 was released.



Changesets are also given more visibility with the new release: they’ve been present in Plastic since day one, but now branches cannot just be created “from a label or baseline” but also from a given changeset, which eases maintenance.
Plastic branch inheritance mechanism is flexible enough to define many different branching strategies and now it can be easily tuned (easier than before) with the usage of smart branches.

A smart branch is just a regular Plastic branch with a link to a starting point. A starting point being:

another branch (in which case it will inherit from the LAST on this branch, implementing dynamically updated inheritance)

a given changeset on a branch (which specifies fixed inheritance from a well defined starting point)

a label (which is the regular case normally used as best practice for branching).

A new changeset is created after a new branch base is set so that users can easily find a checkpoint to be used later on, if needed, to recover this specific configuration.



If you look at the figure above you’ll see that if a developer chooses to go to changeset 99 the branch /main/task001 will use label00 as basis, but label01 if cset 100 is selected.

Changes are also introduced in the selector definition so that now rules like the following will be allowed:

rep “codicetest”
   path “/”
       smartbranch “/main/task001”

And all the required branch inheritance details will be set.

The release BL101 makes all this new functionality available from the GUI and our next release will also introduce support for smart branches from the Branch Explorer.

We expect smart branches to make Plastic branching easier to use for both new and existing users and also introduce more advanced branching scenarios when needed.

Enjoy!

SCM trends at DDJ

The folks at DDJ have just interviewed me about SCM Trends.
I tried to give my own view about the future of SCM and even talked about how threading and concurrency (which I've to admit is one of my favourite topics since long, long ago I first read Ben Ari's book, now there's a new edition available and also the superb Jeffrey Richter's book which is also renewed this year) have an impact in the version control field, or even better how I believe SCM can help there.
I've also focused on why C# was an important decision in the early Plastic development, and more specifically why Mono was actually the key which really opened the C# door for us!

new blog skin

Our blog skin has been changed today to match the website looks and I started to browse old entries.

I found a couple of funny videos showing how to control our 3D version tree with a gamepad and a wii remote.

Just for fun:

The break up, a Clearcase bad love affair

This is the true story of a break up: a sesioned SCM manager tells us why he finally broke up with is beloved system: clearcase.

It probably sounds just like a funny joke, but please read on carefully and find the hard facts behind his disappointment...

Here it goes:

After 12 years working and playing with clearcase I'm fed up with it.
The beautiful lady I fell in love with after my first months in a software development and R&D company became a real pain for me. And a new mother in law, IBM, didn't make it any better.

At the time we met we were doing development for digital media on these nice systems made by Silicon graphics.
It was the time when a system at work was way more powerful, and much more expensive, compared to the silly 486 PC running some version of DOS I had at home. So I went to work with the idea that what I did really mattered for me and the company. After all it was before the bubble.

What I particularly liked about clearcase was the fact that it was completely invisible for the developer.



You set a view and you could start working with any tool you wanted, the sources were right there where you needed them. It was a fast and advanced environment. It had directory versioning, so you could change the structure of your code without trouble. You had advanced branching and merging, you had merge tracking and the branching strategy we used at the time was branching per task. It was possible to do this efficiently in clearcase since it was so good at branching and merging.

And it had all this 12 years ago!

And the stunning fact is that while the world evolves, clearcase chooses the completely wrong direction.

It tried with the ugliest implementation ever conceived for a SCM environment, UCM, Unified Change Management, trying to impose a ridiculous overloaded process on top of the old base. She completely ignored her old lover boy, the developer, while trying to impress those people who hated development. It broke down the whole idea of branching per task.


It gave up on having a consistent user interface on all the platforms it supports, using clearcase on the different flavors of UNIX, Microsoft windows or Linux really is a different thing. The clearcase GUI on UNIX and Linux is really bad. And why has the command line so much more features compared with the GUI? And why is Apple ignored?

The fact that there is no standard way of doing a recursive check-out or check-in, the error messages that seem to be completely unrelated with the real error, the fact that if line endings are changed in textfiles used in a crossplatform environment and the merge and compare tools that fail on these, the fact that the number of characters on a line, e.g. in an XML file is limited and makes the merger fail are all things I could handle.

But the real showstopper comes with the integrations provided to 3rd party tool like eclipse, WSAD, Visual studio etc... , these integrations are in fact only integrations to do a check-in/check-out, all other clearcase operations are a pain in these environments. Simply switching views in an IDE to a view on another branch in the same project is almost impossible, effectively making the entire branching power useless.

While at the old days, clearcase was invisible for the developer, a silent and helpful companion, nowadays it makes a developer's work difficult, slow and cumbersome. Some people even argue that going back to the stoneage of SCM practice, by using tools like CVS or Subversion, is better then using clearcase.

And right at the time when I really needed to feel young again, fresh and excited about software development, a beautiful, open product appeared on the scene, made by developers for developers, all the focus is again on how development and integration can be done in an efficient, fast and powerful way. With a consistent look-and-feel on all the platforms it supports. (it even runs on Apple, a brand ClearCase always ignored), with an easy to use branching and merging environment, with good integrations with your IDE, so switching workspaces to another branch is a very easy and fast task, with merge tracking and correct directory versioning.
In fact with all the good things of clearcase and a solution for most problems it has.

Please go and check-out plastic SCM 2.0 as fast as you can, you won't be disappointed.