Audit options with Mercurial

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com]
>On Behalf Of Dave Brosius
>
>I work for a  large company that was running Clearcase, and we switched
>to Mercurial. Anyone who says that clearcase does anything well, is
>crazy. The productivity gains from the switch where incredible
>especially if you have to use clearcase's multisite, as we did. In my
>opinion Clearcase does everything deplorably poor, and that's from 10+
>years of use and administration. The administration has gone to next to
>zero with Mercurial from a very high level with clearcase. There is no
>comparison.

That's not entirely true.  While Clearcase is certainly dog-slow for many things, it does have some very useful features.  One that we're currently struggling with (and for which I'm in the process of writing an hg extension), is the idea of "activities" (aka bugs).  
Clearcase lets you group multiple commits into an "activity", and then work with that activity as a whole when deciding whether to include some changes in a particular release.
We've traded time spent on management of Clearcase for increased time taken trying to figure out what goes into a build, but we've also saved lots of developer time and frustration just working on code, so it's ended up being a net improvement.

>Now if you are looking for approval management as the OP is, then at the
>very least you will have to build some workflow around Mercurial, as
>this isn't supported directly. To me it would be as simple to having 3
>repositories owned by development, qa, and release. Where each
>repository has it's own set of user access. Commits to the QA repository
>would have some sort of commit message in it from QA describing who
>approved it, The one for Release would show comments documenting who in
>management approved it. Only the approvers would have access to the QA
>and release repositories.

That's what we do.  Although once some code gets beyond QA there is no repository; instead there's a build artifact (i.e. tarball) and only certain people have access to put that tarball in the release area.  Restricting access to QA repositories is quite simple, especially if you arrange the paths on your server such that you only need one "Location" element in your apache config (assuming you're using apache, of course) to specify the access restrictions for all the qa repositories.

eric