Tag after Release
>> Tuesday, March 02, 2010
Last week Eclipse and Equinox 3.5.2 was released as part of the Galileo SR2 release. So far, so good! A big thanks goes out to David Williams for keeping all the projects on the release train in line and ready for SR2. Also, kudos to the webmasters for ensuring that the mirrors were ready for the release.
The work of the release engineer isn't done after the release bits are available. I tag all the projects in the Eclipse and Equinox project with as R3_5_2, as well as our our map files and the builder projects. This ensures that if required, exactly the same build can be reproduced. In addition, it's useful for developers to be able to compare against a tag for a previous release, or to branch from a tag.
Our source resides in the /cvsroot/eclipse and /cvsroot/rt repositories. The steps I take to do this are as follows:
2. Check out the vM2010211-1343 versions of org.eclipse.releng and the builder projects. Every time we run a build, the org.eclipse.releng and builder projects are retagged with with the build id. M2010211-1343 is the build id of the final 3.5.2 build so I retag these projects as R3_5_2.
3. I remove the orbit map from the releng project in my workspace. There are prebuilt bundles fetched from the Orbit repository so we don't need to tag them.
4. Replace :pserver:anonymous with :extssh:kmoir in the remaining map files in my workspace. I have commit rights on all the eclipse and equinox projects for this very purpose.
5. Change the connection timeout on the Team CVS client to one larger than the default. Otherwise, your CVS connection will timeout while tagging all the projects.
6. Select the map files in my workspace. Right click and select Team and the Tag Map File Projects option.
7.Tag as R3_5_2.
8. Once all the tagging has completed after several hours, I will check out all the projects from the map files and compare with R3_5_2 to ensure that there aren't any files missing the tag.
9. Install the releng tools to use the "Tag map file projects" functionality. This allows me to tag the versions of projects defined in your map files as another version without checking them out. Very useful.
Questions?
- Q.Why don't you do this tagging as part of the build process?
- A.Eclipse and Equinox is a large project with a lot of source - over 300 bundles and more than 30 features. Tagging this as part of the the build each time takes a few hours and is often has CVS timeouts. We don't need that, the build is slow enough as it is today :-) That being said, if you have a smaller project of just a few bundles, tagging the bundles with the build id could be useful.
6 comments:
What kind of masochistic release manager even tolerates the use of CVS anywhere near a source tree under his/her control?!? Time outs? Hours waiting for a freaking tag?!? What could possibly be worth that pain and horror?
Seriously, what is the technical reason here? I think the moment where you couldn't tell developers to use something modern/decent/that doesn't suck big time, passed about half a decade ago. Arguably, SVN has been a perfectly good drop in replacement for CVS since it was released in 2005. More recently, people serious about merges, tagging, branches etc. use git.
Jilles. Thank you for your spirited comments.
The CVS timeouts are due to the server infrastructure being overwhelmed, not CVS itself. Tagging many millions of lines of code takes time. Support for git was recently introduced to eclipse.org. The tooling to support git is still maturing within eclipse.
Moving to a new SCM for a 10 year old project with a huge code base is not a trivial undertaking. When we do this it will be a significant plan item that on a release plan. Not only does the tooling within Eclipse have be mature, but the build technology that we use must also support the SCM.
Patches welcome :-)
I know, the point is that it is mind boggling that you guys stuck with CVS that long. In my view it's pure masochism. Apache migrated their CVS to subversion half a decade ago. A pretty big effort, sure, but they haven't looked back.
I know getting rid of cvs has been on the agenda for ages. But release after release, you guys stick with it. Tagging takes ages, branching and merging is a nightmare, it doesn't actually track file renames (that must be horrible with the excellent refactoring in eclipse).
And tagging millions of lines of code only takes that long because you are using CVS. Any more modern solution does that in about 1 second. So add up all the time over the years spent waiting for CVS to do its thing and you probably end up with enough to do a sensible migration to something better.
Big thank you for you for your efforts.
So, for 3.7 you'll be using Git, right?
Post a Comment