Literate Blogging

I’ve been quite lucky these past few months : I’ve been given the opportunity to work on Collaborative features for our next release of Obeo Designer.

We had to make many choices and to define what was, according to us, a good collaborative process. In this post, you will see how Obeo Designer allows you to simply collaborate around models, through graphical representations such as Diagrams, Tables, Trees…

Why does SVN suck ?

I don’t think that I’m teaching anything to anyone here : collaborating on models through SVN can be a real burden.

For example, I often share models with all my teammates (typically our ecore meta-models). In order to avoid any concurrent modification on these models, that would force one of the developer to make a manual merge of the modified models (although this merge can be facilitated by EMF Compare, it remains painful, and quite a productivity killer), I first have to send a notification on skype to warn my team that I take the lock on some model files.

Well, it’s true that it does the work, but when I’m doing this it feels like I’m back to Stone age…

The main purpose of Obeo Designer’s Collaborative features is to avoid manual merge : we would like to rely on a mechanism that allows to lock models in order to avoid future conflicts.

Why cannot any SVN-based tool be the answer ?

As you may know, some SVN-based tools allow to lock files in order to avoid conflict. Although this allows to prevent from any merge if all users lock the files they are about to modify, there are 2 major issues, that we considered as blocking : 

- the lock granularity : locking whole files does not seem to be the best solution when collaborating around models. Indeed, if an xmi file contains 1 000 model elements, and if a user A wants to modify one of these elements, he has to lock the whole model. Hence any other user that would like to modify an element contained in the same resource, but with no link with the element edited by user A, cannot modify the file. Another productivity killer : if modifications cannot be done by several users in the same time, you’re good to spend your day waiting in front of the screen… For Obeo Designer, we wished to have a fine grained lock mechanism, that allows users to lock one single model element, no matter in which resource it is located.

- the real-time updates : if a user A modifies a model element and commits, the other users would have to make an update to see these modifications. For Obeo Designer, we wished all users to see changes made by others in real-time.

Live Collaboration with O.D : example

But enough with the chitchat, here is a concrete example of live collaboration with Obeo Designer.

User A and User B are working on the same model, representing the stock of vehicles that should be repaired in a Garage. This model is located on a server (actually a CDO Repository, but the users do not need to know that).

• User A creates a diagram on this Garage model :

  

• User B creates a table on this Garage model :



• User A decides to rename one of the cars. Obeo Designer automatically locks the modified element to avoid conflict. User A now sees the edited car as locked by him (green padlock) :

  

• User B instantaneously sees that the edited car has been locked by another user, and cannot modify it anymore (but can edit any unlocked element, no matter if contained in the same resource) :

  

  Notice that Obeo Designer uses lock strategies to determine which element should be locked when a modification is made. The default lock strategy locks the minimum set of elements that allows to avoid conflicts, but you can provide your own lock strategies (for example, if a car’s wheel is locked, also lock the wheel disk).
• User A saves his diagram. Saving will trigger a commit on the server. Locks are released as there is no risk of conflict anymore :

  

• User B sees in real-time the modifications made by other users :

As you can see, this automatic locks mechanism allows to avoid any conflict, and the end user does not need to ask himself which elements should he lock before doing a modification.

That said, it seems quite reasonable to let users to lock elements, if they know they are going to work on these elements and do not want to be bothered by other users’ work.

Such locks on demand are not automatically released when the user saves ; he will have to unlock them manually through the Lock / Unlock menu shown above.

End-User experience : is it too complicated ?

One of our main effort was to make live collaboration as simple and transparent for the end-user as it was possible.

• Adding a resource located on the server is as simple as adding a local resource, except that the user will need to enter the server location (no magic here) :

  

• Once it is done, automatic locks and real-time updates do the work without requiring any knowledge from the end-user.

Our first customers feedbacks are enthusiastic, and we can’t wait to release the Obeo Designer 6 to see how people reacts.

Thanks to the CDO team !

We used CDO to develop these collaborative features.

If this name does not ring a bell to you, I strongly advice you to take a look at CDO wiki, and to play a bit with it. It is truly a great framework, extensible, stable and really fun to play with ! Eike Stepper, Martin Fluegge and all the CDO team have been a really great support. I do not think we would have been able to get to this result without them. Just yesterday, Eike fixed an issue less than 30 minutes after I’ve opened it. Thanks a lot guys !

And there is much more…

Well, there is truly a lot to say about these collaborative features, I’ll definitely write new posts to show you representations sharing (in this mode, the users also share their diagrams, tables and trees), changes serialization (so that an end-user can save locally its work without committing it, keeping the locks to avoid conflicts), user identification… We also have many cool features in mind, I’ll present these when time will come ;)