You'll need someone to give you a nice, gentle introduction. I've long since elbowed out all other version control systems in favour of using this colourfully-named version control system exclusively. If you like, I'll come along and be the one to give you that gentle introduction.

Git is a powerful, distributed version control system that is particular well-suited for large development projects that include numerous parallel development branches. The Linux Kernel developers use it for heaven's sake, a project with thousands of contributors. Last I checked, Linux recently went beyond 15 million lines of code. Nevertheless, Git is just at home servicing more humbly-sized projects too.

I ordinarily cover the following core topics:

I've updated my business website with details of the course. For the full curriculum visit the Subversion course page. Broadly speaking, the course covers:

• Subversion's architecture and philosophy
• Clients you can use to interface with the Subversion server (especially command-line, TortoiseSVN or Eclipse integration)
• The basic workflow
• More advanced concepts
• And numerous tips and tricks to make life easier.

In this case, the course was customised to cover certain topics in more detail, in particular the philosophy (because the participants were converting from a version control system with rather a different approach to things) and externals (because the company had another branch in the USA where important software libraries and components were maintained).

The training went well in my opinion. The participants managed to grok the fundamental changes from CVS to Subversion; they all got hands-on experience playing around in sandbox repositories, trying to solve tasks I gave them; and they all seemed very curious, chatty, and generally engaged in the course.

In fact, this last point taught me a little something as a teacher. Most of the teaching and training I've done before has been for large companies and universities, places with teaching facilities like large rooms or auditoriums, where I stand at the front of the room with my pointy stick and the participants sit at individual desks. In such cases, it all feels very much like I'm lecturing to a group of students. This time around however, there was no such venue available and the training was conducted in a meeting room (albeit a typically technical one with a projector and Ethernet cables and so on).

So there the participants were, not all facing me like in a schoolroom, but sat with me around a table, more like a meeting or a seminar. I still presented a series of slides, but the conduct of the lesson was much more relaxed and casual. One effect this had was that people seemed much more willing to ask questions when they didn't understand something. Another (and the really cool one, I think) is that there was a lot more self-teaching going on. When one participant asked a question, another participant sometimes beat me to it and started to answer them (occasionally with one eye on me, as if to ask silently "Am I getting this right?") Thus, my role there was not so much to lecture them as it was to help them teach themselves -- which, by the way, has always struck me as the most effective way to learn a topic.

I think this looser and slightly chaotic approach worked really well. Until now, I wasn't so insisting on where a training took place. From now on, I think I'll consider a round-table approach to teaching much more carefully, even when an organisation is lucky enough to have grand lecturing facilities.

In the past, patches were passed freely around on the project's mailing-list. Team-mates could take each other's patch files, apply them manually and conversations proceeded in mailing-list threads. While it did the job, it was somewhat cumbersome and only grew worse when the team grew in size. To improve matters, we chose to use ReviewBoard.

ReviewBoard is a web application that links to a project on your VCS. When you make local changes and produce a patch file, you can then upload your patch to ReviewBoard, which will compare the patch to the repository version and manage the diff for you. By "manage the diff", I mean things like:

• Produce a two-pane diff view, showing what has changed
• Allow you to attach both general and line-by-line comments on the code
• Make multiple versions of the same patch
• Aggregate all feedback into a single thread
• and so on...

In our time using ReviewBoard, it has become an extremely helpful tool indeed. I think it would cause us to go cold turkey if it were taken away (although perhaps not as powerfully as losing code completion would -- I've been there, it wasn't pretty) . This post is simply to express my own support and gratitude to the makers and to point out that any sizeable team of software engineers could do a lot worse than use such a tool to manage their review process (you do have a review process, right?)

I also thought about passing on some advice about using ReviewBoard, which we at Saros have gathered, but I've been beaten to it by others on the Interweb, most notably by KDE's Aaron Seigo. Otherwise, read a good software engineering handbook for the more general inspection stuff.

There are however a couple of additional tips I could pass on:

• Due to one of the unusual quirks in the way Saros team functions, we typically have a only single team-member producing a new feature. Something like a new feature means a lot of new code and therefore a big patch. (Reviewing a two-thousand line patch makes me yearn for something less painful, like root canal work.) This is where ReviewBoard's multi-version helps.
  1. Our team's policy is that an in-progress feature should be broken up into small milestones and a permanent review request is opened for that feature.
  2. A patch is posted at each milestone and reviewed. It can still be updated at this point, but as soon as it is approved (at, say, version N) , all changes made thus far are therefore approved up to version N.
  3. At the next milestone, when the same review request is updated, you don't have to review everything, you just ask ReviewBoard for the differences between N+1 and N.
  This way, the effort required for reviewing a monster feature is kept under control.
• ReviewBoard does a lot of work dynamically that requires it talks to your VCS. If, like us, your VCS is kept on a less than speedy server, ReviewBoard can be slow. We solved this by connecting ReviewBoard to a self-hosted, read-only mirror repository that is much quicker and makes for a much more enjoyable experience.

To quote some interesting passages from the release notes:

The integration of version control support (VCS) into Saros has been given its final consolidation. Developers can now collectively work on a project under version control and Saros will manage the co-ordination between the participants whether they have VCS software or not.

Note that so far Saros is only compatible with the Subversion program. We hope to include other popular VC systems in later releases.

We have also improved the perceived latency of Saros by lowering the interval time between which your updates are sent to your collaborators. In the unlikely event that this causes overload problems for the XMPP server, it can now be configured to a higher value.

Whereas Saros used to enforce the latency of transmitted edits itself (present out of courteousness; after all, Saros can use public servers and we wouldn't want to overload them) we are now passing that power onto you. The rate at which your edits are transmitted to others in your session is now configurable via the advanced preferences, which now comes pre-set to a lower value to give you a more responsive feel. Use your fearsome new power wisely!

Get Saros today from http://dpp.sf.net/update, or visit http://www.saros-project.org for more information.

Thanks to all those who took part! Maybe I should take another poll: who has the best logo, Eclipse or Git?

Edit: See the previous post to find out why Subversion is not included in the results.

You may be familiar with Saros -- our plug-in which provides distributed collaborative editing in Eclipse -- and you may even know that Saros now features version control system (VCS) integration, so that all participants can work directly on the project repository together. At the moment, this feature only supports Subversion, but thanks to some clever architecture we can easily chuck in a bit of new code to support any VCS we like. But our resources are limited, and in lieu of a contributor coming forward and writing their own code (which is always welcome!), we have to pick and choose which VCS to support next.

To help us decide, please take a few seconds for this poll. The most popular VCSes are included, but feel free to add others.