Mike Kupfer <mike.kupfer at sun.com> writes: > One of the markets for Solaris is the secure computing environment, > which involves a formal security evaluation[1] of the OS and the > processes that are used to produce it. Part of the evaluation involves > looking at how changes to the code are managed. > > Jane Medefesser sent me a brief overview of what sorts of things get > reviewed, and she included a copy of the relevant Common Criteria > documentation. I've looked it over, and since life under Mercurial will > look a lot like life under TeamWare, I don't expect the conversion to > Mercurial to affect CC evaluation much. > > I do want to send Jane a list of relevant differences between TeamWare > and Mercurial, to see if she sees potential stoppers. I've attached a > draft write-up. Please let me know by next Tuesday (end of the day, > 18th March) if you see anything that is incorrect, or if you think I've > left out something important. > > thanks, > mike > > [1] http://blogs.sun.com/jimlaurent/entry/faq_what_is_a_common > > Operations under Mercurial will look a lot like they do currently > under TeamWare. There will be some differences in the areas of > auditing and access control. > > * logging > > We will generate per-putback emails, as we do today with TeamWare. > The format will be slightly different. In particular, renames will > appear as a list of deleted files and a separate list of created > files.
This is true, but does not *have* to be true, it's just a matter of how that code was written (you could do the same stuff cdm does, and get the same info, if you wished). > It is also possible to view the changes to the gate using "hg log". > Unlike "sccs prt", this command shows changes across the entire > repository, not just for a single file. You can specify a filename to hg log, just as you would with prt, you can also specify that you want to follow that history across renames/copies, and various other things. The way you've written that makes it seem like you have to see the entire log across the whole gate, you don't. > * RTI enforcement > > We will initially enforce RTIs the way we do now, by checking each > putback to ensure it has an approved RTI, and manually following up if > it doesn't. > > Eventually we plan to configure the gate so that the putback is > blocked if there isn't an approved RTI. > > * user identification > > The Mercurial user can specify an arbitrary name and email address, > which Mercurial will record as the author of a changeset (revision). > This is not that different from the situation with TeamWare/SCCS, > in which deltas can be checked in using a dummy account. Right. > Mercurial does not keep a per-putback history file the way that > TeamWare does. True, but that's because the *only* history it keeps is, by those terms, per-putback. > As mentioned above, we do generate per-putback emails, > which can go to a logging alias. However, the email's From address is > based on the author information in the changeset; the user name of > whoever is actually doing the putback is not recorded. We have a CR > (6639131) to change this, i.e., so that the notification email comes > from the person doing the putback, but it is not currently on our > stopper list for the move to Mercurial. We never fully looked into how we would go about doing that. It's tempting to suggest we look at the notification extension delivered with mercurial, which, ideally, would save us both from maintaining our own, and from having to update our own as mercurial changes. (though I'm not sure what the stability of the notify config options would be, I'm almost certain it would be better than the internals...) -- Rich
