Hi,
We're working to include version control in mbed to help with code development, and eventually as a backbone to collaborative development.
The approach we're taking should be familiar to those of you with experience of distributed version control models (as used by mercurial/git); we want each program to have its own local repository, so you can commit and perform actions on that totally within your own workspace (such as updating, branching, showing changes). You can then publish changes or pull changes from another (often centralised) repository, to enable collaboration.
If you have an understanding of some of these concepts, we'd be interested if you want to try out what we have so far. Given there is no public documentation yet, it'll be interesting to see how you get on and will in some ways be a good test of the UI!
The main things you should be able to do so far are:
- Commit a version of your project, and view the revision history
- View changes a version made, and compare changes between versions
- Update or revert to a different version
- Branch and merge
Note that you can't do any collaboration aspects with this yet; no pulling, pushing, named branches etc; it is all just local to your workspace project for now.
To give you some clues, here is a quick outline:
Your program, as before, is the "Working Copy". You can "Commit" changes to its local repository to create new "Revisions". You can see the changes between your current working copy to the previous revision, and changes between revisions.
You can choose to "Update" to a particular revision, which updates your working copy to that revision (e.g. a state of your program in the past). This is the way you can "Branch"; do some commits, update to a previous revision, do some more commits; you now have two branches of development derived from a common revision.
You can then "Merge" a revision, often the head of one branch, in to your working copy. This creates a working copy that is the merge of these two branches, and when you commit, your back to one (less) branch of development.
There is also the option to "Discard" your working copy, and "Revert" your working copy to a particular revision; unlike "Update", this creates a working copy with the changes you need to get back to that previous state, more like an "undo" than a branch.
We've put it live on our beta site, so if you want to test it out, you can enable betamode by visiting this link and following the instructions:
The beta is a beta for a reason, so of course we don't recommend you use this on active/important projects quite yet. Please try it out, see how you get on, and report back here with any thumbs up, bugs, comments, etc...
Have fun!
Simon
Dan Ros.
12
replies
Hi,
We're working to include version control in mbed to help with code development, and eventually as a backbone to collaborative development.
The approach we're taking should be familiar to those of you with experience of distributed version control models (as used by mercurial/git); we want each program to have its own local repository, so you can commit and perform actions on that totally within your own workspace (such as updating, branching, showing changes). You can then publish changes or pull changes from another (often centralised) repository, to enable collaboration.
If you have an understanding of some of these concepts, we'd be interested if you want to try out what we have so far. Given there is no public documentation yet, it'll be interesting to see how you get on and will in some ways be a good test of the UI!
The main things you should be able to do so far are:
Note that you can't do any collaboration aspects with this yet; no pulling, pushing, named branches etc; it is all just local to your workspace project for now.
To give you some clues, here is a quick outline:
Your program, as before, is the "Working Copy". You can "Commit" changes to its local repository to create new "Revisions". You can see the changes between your current working copy to the previous revision, and changes between revisions.
You can choose to "Update" to a particular revision, which updates your working copy to that revision (e.g. a state of your program in the past). This is the way you can "Branch"; do some commits, update to a previous revision, do some more commits; you now have two branches of development derived from a common revision.
You can then "Merge" a revision, often the head of one branch, in to your working copy. This creates a working copy that is the merge of these two branches, and when you commit, your back to one (less) branch of development.
There is also the option to "Discard" your working copy, and "Revert" your working copy to a particular revision; unlike "Update", this creates a working copy with the changes you need to get back to that previous state, more like an "undo" than a branch.
We've put it live on our beta site, so if you want to test it out, you can enable betamode by visiting this link and following the instructions:
The beta is a beta for a reason, so of course we don't recommend you use this on active/important projects quite yet. Please try it out, see how you get on, and report back here with any thumbs up, bugs, comments, etc...
Have fun!
Simon