[
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. ;-)
Mik:
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()
https://bugs.eclipse.org/bugs/show_bug.cgi?id=123456
or
https://bugs.eclipse.org/bugs/show_bug.cgi?id=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:
http://www.eclipse.org/emf/searchcvs.php?q=author%3Anickb+skrypuch+patchThe other is to provide contributor details in Bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=161744#c10This is useful when you have to concoct your project IP log - you can just query Bugzilla for "[contrib" to find all your NCCs:
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&classification=Tools&product=EMF&long_desc_type=allwordssubstr&long_desc=%5Bcontrib
Cheers,
Nick
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
bugs.eclipse.org bug the above
would resolve to:
RESOLVED - bug 161626: Jumping tasks in
workweek Task List
https://bugs.eclipse.org/bugs/show_bug.cgi?id=161626
Mik
+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
lmandel@xxxxxxxxxx
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?
http://wiki.eclipse.org/index.php/Development_Resources
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.
>
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=164719
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=153838
>
> 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:
>
> http://wiki.eclipse.org/index.php/Image:Search-cvs.png
>
http://wiki.eclipse.org/index.php/Image:Release-notes.png
>
> To try out Search CVS, go here:
>
> http://www.eclipse.org/emf/searchcvs.php
> http://wiki.eclipse.org/index.php/Search_CVS
>
> 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 ::
http://www.eclipse.org/modeling
> http://wiki.eclipse.org/index.php/User:Nickb
>
_______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. --
http://www.eclipse.org/
Office: 613.224.9461 x224
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev