Chris Johns recently made an announcement to the RTEMS Users mailing list which gave the status of the CVS to Git conversion process. Read that email for details and watch the Users' List for follow ups. Feel free to ask questions and report issues. This is a big transition and we all have learning to do.

There was positive reaction in public but someone politely noted in a private email to me that this was the first they had heard of it. It really was a nice way of saying.. "Hey.. you forgot to say anything until it was almost done!"
[

I was surprised to see that RTEMS is moving from CVS to git. I've searched the wiki but haven't found any info as to why the change was/is being done. Perhaps a link on http://git.rtems.org/ to the reason(s) for the change would be a good idea. The last I seem to recall (and I'm sure my memory has more than a few read errors) there was no plan to move from cvs to another source code control system.

Everyone on the RTEMS Project knew that CVS was old and had deficiencies like moving or renaming files, etc. We had briefly looked at moving to SVN years ago but it wasn't enough to be enticing. We just never had a pressing reason to move from CVS and incur transition pain. That is .. until now..

Chris Johns and I met Amar Takhar of the Network Time Protocol (NTP) Project at the GSOC Mentors Summit in 2009. Amar was intrigued by the variety of target architectures and number of BSPs we had to support in RTEMS. He thought it would be challenging and fun to set up an automated BuildBot for RTEMS. On each check in, the BuildBot would automatically build all impacted configurations, run tests, log failures, send emails, etc.. It would be an invaluable tool for catching errors as soon as they are introduced. Amar got the buildbot installed and working but it became apparent that CVS not providing atomic change sets resulted in not having good input to the build bot. Without an atomic change set coming directly from the Revision Control System, there is no way to be sure that you are building because of a complete change. As we all know, Garbage In, Garbage Out.

In addition, Jennifer and I were in the middle of trying to track the CVS head and merge our SMP changes. It was very difficult with CVS. Large changes like SMP or a TCP/IP stack upgrade are painful to manage over the course of months in CVS. Fighting CVS was painful but wasn't enough to drive a switch.

Ultimately, the atomic change set requirement was the straw that broke the camel's back and initiated the planning of the conversion to git. So we starting planning the change. The plan is at http://devel.rtems.org/wiki/Projects/CVStoGit. This is not a decision we made lightly. RTEMS has 17 years of CVS history. We don't want to negatively impact that history in converting to another Revision Control System.

About the time I started to wonder if the RTEMS Project was suffering because we do not periodically evaluate the tools we depend upon and our development processes. It is only natural to accept the status quo because we are all human and use what we are familiar with. But, on the other hand, many of the tools RTEMS depends upon are newer versions of the same ones we used 10+ years ago. Those tools were the best of breed when we selected them. Are they the best solution now? If given a clean slate, would we pick them again? I don't know. I only know we need to use best of breed tools and processes to produce the best real-time operating system possible.

The transition to git and adoption of a BuildBot are the first step in what I hope will be a continuous improvement process for the RTEMS Project. Please hold on during the transition and help out. This is a learning experience for us all. Ask questions and report problems.