[cross-project-issues-dev] CVS commit conventions / best practices / fre

["Nick Boldt" <codeslave@xxxxxxxxxx>]

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