I realized that despite the importance for software development, many folks are largely unaware of the features and power their S(ource) C(ode) M(anagement) tool can provide them. In my group, we use Mercurial<\/a>. It is an awesome SCM and perfect for our team (which is largely Python writing) as it is written in Python. However, as with any tool under development, there are features which were not mature when we started using Mercurial, or otherwise, we have just never taken advantage of some features despite their obvious use.<\/p>\n For us, we have a release of OpenSolaris every six months roughly and to prevent stopping all non-release development, we will fork our source base into a release and development (non-release targeting) code base. The first time I did this, as the gatekeeper (what we call the team’s build maintainer and release engineer) I simply created a second Mercurial repository — this was for the OpenSolaris 0906 release. This repository mirrored our slim_source<\/a> Mercurial repository. All was well. Further, this required the team to hold a dead code base around (the now dead slim_0906<\/a> repository for the similarly named release). If we want to know what changes made that release we must clone<\/a> in and go through it trying to compare it to our main-line code base slim_source<\/a>.<\/p>\n This was awesome to know, for as a gatekeeper one becomes far more intimate with the SCM than most developers need to be. But it also questioned the power lurking underneath the SCM. For Mercurial can address all these issues easily:<\/p>\n Given these issues and the potential fixes, I figured I should try and help the developer community using our code base learn these new tools. Further, trying to automate as much as I can, using Mercurial named branches<\/a> was a key thing to keeping all of our source code in one repository for later reference and analysis. Though, it meant going beyond established OpenSolaris territory of Mercurial use as to my knowledge no other team is using named branches on hg.opensolaris.org yet.<\/p>\n Named branches caused some issues!<\/p>\n First, the OpenSolaris developer environment uses community-developed extensions called Cadmium. These are to mimic some tools which Sun’s previous TeamWare software provided as the Solaris SCM of old (such as our recommit extension). Other features are simply to establish standard operating procedure for development (like webrev’s as can be seen at cr.opensolaris.org<\/a>). These Cadmium extensions were developed assuming no-one would be working on branched code bases.<\/p>\n Luckily, since we rely on Cadmium’s recommit the IPS<\/a> folks had talked about the issues of using branches before. Rich Lowe<\/a> in particular already even However, then as development continued, we found that there was an issue on our gate machine. The gate machine for the OS\/Networking<\/a> consolidation is different than hg.opensolaris.org so that the ON gatekeepers can configure their own Mercurial gate-hooks<\/a>. On our gate machine hg.opensolaris.org we can not configure our own gate-hooks, and this caused us issue as the gate machine, of course, will accept one making or merging a branch in the source code base.<\/p>\n Mercurial, will of course, let you happily close a branch (e.g. hg commit --close-branch slim_1003<\/tt>). However, we found folks could do interesting things like:<\/p>\n These two cases, though undesirable to our community, would happily be accepted by hg.opensolaris.org into our slim_source repository and require lots of coordination to revert their affects. So the answer was to write a Mercurial hook. But this hook would be a client-side hook.<\/p>\n As such, with the help of Dave Marker<\/a> we were able to craft a user-side hook to check if all pushes were continuing on the same branch or if someone is jumping branches. This hook needs to be added to an hgrc file in you path. For a build machine, this can be \/etc\/hgrc<\/tt> or for a user you can use your ~\/.hgrc<\/tt>.<\/p>\n
\n<\/p>\n
\nThis approach illustrated three areas of uncertainty with developer understanding, however:<\/p>\n\n
\n
The idea<\/h1>\n
Issues<\/h1>\n
had a potential fix for hg recommit<\/tt> ready for codereview<\/a>! Putting this in place until it is accepted into the OpenSolaris SUNWonbld package simply required sending a heads-up<\/a> to the slim_source developing community to install the updated Cadmium files.<\/strike> has integrated into build 134 and later (see the changeset log for build 134<\/a>) a fix for bug
\n6922488 – cadmium recommit should be more relaxed about in-repository branching<\/a>. To use the new code do nothing more than pkg image-update<\/tt> to build 134 or newer and your pkg:\/developer\/build\/onbld<\/tt> package will be updated!<\/p>\nCase 1<\/h3>\n
\r\nhg clone ssh:\/\/anon@hg.opensolaris.org\/hg\/caiman\/slim_source\r\nhg update -C
Case 2 (simply merge the branches)<\/h3>\n
\r\nhg clone ssh:\/\/anon@hg.opensolaris.org\/hg\/caiman\/slim_source\r\nhg update -C