[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS auditing improvement
CVS auditing improvement
Wed, 5 Nov 2003 12:34:33 -0500
Recently, we had issues at my company which revolved around CVS branches
being forgotten. That is, work was done, but the branches were never merged
on to the mainline. While this is a mistake on the developers' part, that
is of little comfort to the project manager who is responsible for the
I did some research and I have not found a good way to audit the lifecycle
of a CVS branch. That is, I can't tell when a branch was created, why it
was created, and which branch it was ultimately merged with, or when. Or if
it was even _supposed_ to be merged back. cvs's history command can give me
some of the information, but not all of it.
I'll restate my requirements. I want to know
1) when a branch was made
2) why a branch was made
3) who made the branch
4) the disposition of a branch. Is the work good? incomplete? a dead end?
5) the branch into which this branch was merged
6) when the merge happened
7) who did the merge
8) any annotations about the merge
9) any annotations about the branch in general
1) a module named WTF
2) WTF's current production codeset is tagged REL5.
3) WTF's current fixes are in branch REL5_fixes
4) All work is done remotely using pserver. No one logs directly on to the
CVS reposity box. This changes how things are logged in the history,
Fred notes that in REL5 of WTF, their company's name is misspelled 20 times.
He bugts this using Bugzilla, which tags the issue with id 100. The bug is
assigned to developer Stan.
Stan creates new branch called "stan_05nov_bugs" which is rooted from REL5.
He annotates the creation with "bugz 100 - We can't spell".
Stan changes 20 files over the next 2 days.
Stan commits the changes, using -m "now we can spell"
Stan is assigned another bug, bug 102. Already having a working branch, he
elects to use it for 102. He annotes this "Also working on bugz 102 -
divide by zero in main.c"
Stan fixes the bug in main.c and commits the changes, -m "FYI bug was really
Stan calls Mary in testing so she can bless his changes.
In the meantime, Stan's hare-brained boss wants changes, which over the next
few days turn out to be impossible. This results in...
A new branch from REL5 called "harebrained", and annotated as, "perpetual
the annotation, "No, there was some friction"
another annotation, "This branch is dead"
His changes are ok'd by the Mary of testing crew a week later.
Now he merges "stan_05nov_bugs" into REL5_fixes. He annotates this with
"Fixed bugz 100 and 102"
At this point, the project manager should be able to type a command and see
stan,05nov2003,new_branch,stan_05nov_bugs,REL5,"bugz 100 - We can't spell"
stan,07nov2003,commit,stan_05nov_bugs,"now we can spell"
stan,07nov2003,annotation,stan_05nov_bugs,"Also working on bugz 102 - divide
by zero in main.c"
stan,07nov2003,commit,stan_05nov_bugs,"FYI bug was really in queue.c"
stan,09nov2003,new_branch,harebrained,REL5,"perpetual motion patent"
stan,10nov2003,annotation,harebrained,"No, there was some friction"
stan,11nov2003,dead,harebrained,"This branch is dead"
mary,14nov2003,annotation,stan_05nov_bugs,"works for me"
stan,15nov2003,merge,stan_05nov_bugs,REL5_fixes,"Fixed bugz 100 and 102"
This is off the top of my head of course, the dates should be full
timestamps and so forth. Note the line types - new_branch, commit,
annotation, dead, and merge. These relate to the requirements above. They
are explicit, and allow the associated comments to fill in the details.
Also, imagine 4 developers working on REL5 at the same time - keeping track
of the branches might not be so easy. Yadda yadda.
But the idea is that we have confidence that the work was done and not left
dangling. If the reporting tool above didn't find the "merge" (or "dead")
line for a branch, I'd expect to be warned. I'd also expect
loginfo/taginfo-like/modules support for the new annotations and so forth.
|[Prev in Thread]
||[Next in Thread]|
- CVS auditing improvement,
Tony Ennis <=