Mbed OS 2 and Mbed OS 5
This is the handbook for Mbed OS 2. If you’re working with Mbed OS 5, please see the new handbook.
What do we have now?¶
Right now the majority of the above features already exist within mbed.org.
Regular users will be familiar with publising and importing programs and libraries, which has been a very popular feature, with over 7000 versions of programs and libraries published.
However, some types of more collaborative workflows are more difficult than they should be.
For example it's not easy to really work together on a program or library, because:
- It's difficult to see exactly who changed what code and when.
- There's no way to automatically merge two sets of changes to a published program
- There's no way to allow other people to make changes to a published program
Furthermore some of the underlying technical details of how code publishing works on mbed means that we have ruled out gradual improvement or tinkering around the edges; a completely new approach is required!
Here's what we built.
First, we should define some terminology. For the purposes of discussing collaboration:
- The mbed IDE is the Client
- The mbed.org website is the Server
Everything within the Client is private and completely seperate from the mbed.org website (the 'Server'). Therefore collaboration with the outside world can only happen in the context of going via the Server.
Given that mbed is currently a quite self contained environment, we are in a slightly unique position of being able to control both the client and the server. This is contrast to other web based collaboration systems such as Github (http://github.com), Google code (http://code.google.com) and Bitbucket (http://bitbucket.org). We could design any system we wanted.
However, we have chosen to make mbed collaboration 2.0 non-proprietary. There's several reasons for this including:
- Not reinventing the wheel - version control is not a unique problem to mbed
- We benefit from the great work done by others in this field
- The system we design will be more familiar to those with experience of similar systems
- Keeps our options open for improved integration with external tools
After evaluation of several different approaches, we have chosen Mercurial (http://mercurial.selenic.com/) the foundation of our collaboration system. This again is for a number of reasons, including:
- Mercurial is a distributed version control system which enables the peer to peer development model we are aiming for. More at (http://en.wikipedia.org/wiki/Distributed_revision_control)
- Mercurial is well supported by a variety of languages and tools across several platforms (Windows/Mac/Linux)
- Mercurial is actively developed and used by a large number of projects
- We felt that Mercurial is easy and logical to use on the commandline
- Mercurial is written in Python, and so is a lot of mbed.org, so the integration is a lot smoother