Skip to main content

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

yes, we use that too in the Eclipse projects


Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

11/16/2006 04:21 PM

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

Europa Build Workshop <europa-build-workshop@xxxxxxxxxxx>, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Neil Skrypuch/Toronto/IBM@IBMCA
Re: [europa-build-workshop] Re: [cross-project-issues-dev] CVS        commit conventions / bestpractices / free benefits

Why not use the ‘contributed’ keyword in bugzilla?  We use it for our IP Query in GMF.


On 11/16/06 3:49 PM, "Nick Boldt" <codeslave@xxxxxxxxxx> wrote:

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() <> 123456
  or <>
123456 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:  <;classification=Tools&amp;product=EMF&amp;long_desc_type=allwordssubstr&amp;long_desc=%5Bcontrib>



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
Thursday, November 16, 2006 11:03 AM
Cross project issues
cross-project-issues-dev-bounces@xxxxxxxxxxx; Europa Build Workshop; Cross project issues

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 <mailto: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>    

To   Cross project issues  <cross-project-issues-dev@xxxxxxxxxxx>    
cc   Europa Build Workshop <europa-build-workshop@xxxxxxxxxxx>    
Subject   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


Richard C. Gronback
Borland Software Corporation
+1 860 227 9215
cross-project-issues-dev mailing list

Back to the top