Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] CVS commit conventions / bestpractices / free benefits

Thanks everyone, for all the +1s! I wasn't sure how this evangelical soapbox would be received. ;-)


Your commit comment template is certainly valid, and will be parsed by the current tool, but it's overkill - CVS bloat, if you will. Here's why.

Putting bug status in CVS is not necessary (it's in Bugzilla!), nor is putting in BOTH the bug # and the bug URL, since the URL contains the bug # and that's one of the several supported CVS commit comment syntaxes that our tools support. If your ${ task.description} is the same as the value in Bugzilla (bug title/summary) then that's redundant information too - the comment ought to be something more meaningful than the bug's title, or else nothing. All you need is:

[123456] fixed the foobar doohickey in method baz()

But since Mylar currently doesn't allow for [] wrapping of bug numbers (does it? your screen shot seems to imply new features I haven't seen the version of Mylar I use), then the other way to write this would be:

fixed the foobar doohickey in method baz()
    or fixed the foobar doohickey in method baz()


One additional thing not mentioned in the bugs below or my original soap box is that we also employ a couple other conventions for identifying non-committer commits (NCCs). One is to use {username} in the commit comment:

The other is to provide contributor details in Bugzilla:

This is useful when you have to concoct your project IP log - you can just query Bugzilla for "[contrib" to find all your NCCs:



On 11/16/06, Mik Kersten <beatmik@xxxxxxx> wrote:

+1 for standardizing on this.  I *really* like Release Notes feature.


What is the commit comment convention?  I last recall it being "bug 123", and I want to make sure that Mylar's default template works for the convention (we use this template for automatic commit messages and for mapping from History view entries to bugs/comments).  Is it just ensuring that "bug <id>" is somewhere in the text?



For a bug the above would resolve to:


RESOLVED - bug 161626: Jumping tasks in workweek Task List




From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Lawrence Mandel
Sent: Thursday, November 16, 2006 11:03 AM
To: Cross project issues
Cc: cross-project-issues-dev-bounces@xxxxxxxxxxx; Europa Build Workshop; Cross project issues

Subject: Re: [cross-project-issues-dev] CVS commit conventions / bestpractices / free benefits


+1. Let's standardize this across Eclipse. With this standardized I can see cool additions to the team tools coming... (please?)

Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920

Denis Roy < denis.roy@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

11/16/2006 08:16 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


Europa Build Workshop <europa-build-workshop@xxxxxxxxxxx>


Re: [cross-project-issues-dev] CVS commit conventions / best practices        / free benefits




I think consistency like this can only be a good thing.  Perhaps should
this practice be part of our Open Source Process?

Should there be a blurb about this somewhere here?

Nick Boldt wrote:
> Hey everyone!
> In exploring the various conventions people use when committing
> changes to CVS associated w/ specific bugzillas, I've discovered that
> there are more than a *DOZEN* ways people identify bugzillas.
> Why does this matter?
> Well, suppose there was a tool that could query both Bugzilla and CVS
> to tell you what files were changed for a given bug, or who fixed a
> bug, when it was fixed, and see the actual fixes made (ie., with
> viewcvs diff).
> But wait, don't order yet! Just look what else you get! ;-)
> Suppose that a second tool was being built to generate release notes
> from that database of commit comments and bugzilla details, using
> nothing more than a simple relationship between CVS branch
> (R2_2_maintenance), release version (2.2.2), and buildID
> (S200610121234).
> Suppose you're a small project who doesn't have the manpower to
> statically generate release notes, lists of changed bugs, and lists of
> files changed by bug, but want to provide good project management &
> change auditing.
> Or maybe you don't care... until you have to backport something
> between branches, and need to quickly dig up where you did the change
> in HEAD to apply it to your maintenance branch, in a file you've
> updated 20 times since. Given only the bug number, how quickly can
> you find all affected files, and see the actual deltas?
> Or maybe 20 people all commit things concurrently into a large cvs
> repo and ONE of them committed a typo and now your build's broken.
> Wouldn't it be handy to know who made the changes between the last
> good build and the broken one, to be able to better diagnose where the
> error occurred? Sure, you could generate a static cvs log, but what if
> you could just query between datestamps (good build to bad build) for
> a list of commits, including author, bugzilla (# and link) and actual
> recorded cvs delta (viewcvs)?
> Suppose these tools existed as Phoenixized web pages, and all you had
> to do to get them to work was:
> a) adhere to a consistent commit comment convention (say that 5 times
> fast!)
> b) add your cvs repo(s) to the index (really, that's just `cvs checkout`)
> c) provide details about the three-way mapping (cvs branch : version :
> buildID) on a regular basis, such as with an RSS feed
> Screen shots:
> To try out Search CVS, go here:
> The Release Notes part is still being fine-tuned in order to support
> nested projects, but should be live shortly.
> If you have any questions or would like to be added to the index so
> you can see your commits in Search CVS (try before you buy), drop me a
> line and I'll give you a hand.
> Act now, operators are standing by! 8-)
> --
> Nick Boldt :: Release Engineer, IBM Toronto Lab
> Eclipse Modeling ::
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx

Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc.  --
Office: 613.224.9461 x224
Cell: 819.210.6481

cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top