| Re: [europa-build-workshop] Re: [cross-project-issues-dev] CVS commit conventions / bestpractices / free benefits |
| Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx 11/16/2006 04:21 PM
|
|
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
lmandel@xxxxxxxxxx
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?
http://wiki.eclipse.org/index.php/Development_Resources
<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: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
>
--
Richard C. Gronback
Borland Software Corporation
richard.gronback@xxxxxxxxxxx
+1 860 227 9215_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
