info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Preserving annotations across merges?


From: Chris Johnson \(chjohns2\)
Subject: RE: Preserving annotations across merges?
Date: Thu, 23 Aug 2007 11:12:30 -0700

Arthur and Yves,

Thanks for both of your quick replies. Here is my situation, we use a
tool called Jtest from Parasoft, which runs static analysis and unit
tests on our code base. One of the really nice things it does is if it
detects an problem on a certain line of code it uses CVS annotation to
determine who was the last person to edit that line and assigns the
problem to that engineer. Here is where my issue comes in; we have
multiple branches and many developers, so we rely on merging to get bug
fixes and new features applied from one branch to another, double
committing isn't an option with the number of developers and branches.
When we merge, one person is doing the merging and if any of the code
has an issue, when the person doing the merge commits it, he will now be
assigned all of the problems detected by Jtest on the merged code. Now
the obvious answer to this problem is that we should make sure all Jtest
issues are resolved before the merge, and while I agree this would be
ideal, in our case it isn't practical. I was hoping that there would be
some clever way to have the merge also merge the annotations, so
ownership would move across merges like the changes. It appears that I
was correct in that here is no way to do this currently in CVS.

Again thanks for the responses and if anyone does have a clever way to
solve my problem or even suggestions I'd appreciate hearing from you.


Regards,
C.J.

Chris Johnson
Senior Software Engineer
Wireless Business Unit
Cisco Systems

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message


-----Original Message-----
From: Arthur Barrett [mailto:address@hidden 
Sent: Wednesday, August 22, 2007 9:09 PM
To: Yves Martin; address@hidden; Chris Johnson (chjohns2)
Subject: RE: Preserving annotations across merges?

Yves/Chris,

> I'm not sure but I think this information is not kept in Subversion 
> either. Maybe the future merge tracking will provide enough 
> information to annotate source properly.

Merge tracking is already in CVSNT (linux/unix/windows LGPL/free, just
like CVS) of course (along with every other subversion "feature" plus
the ones they haven't even realised they need yet, like failsafe
auditing).

The original post is raising an interesting "problem".  CVSNT has
"change sets" (bug numbers) that can identify each change (in the same
way as author does) as well as commit id's (like subversion has) that
identify each commit.  Physically in the RCS file they occupy the same
"space" as the author.

I've thought for a while that commit id's and changesets/bugids should
display in the annotate output - but the format is rather fixed so it's
a little difficult.  But of course it would be possible to substitute
the author column for the bugid/changeset/jobid (or the commitid).

Then if you commit bug 123 on branch B and merge it to branch A using
bug id 123 and then commit it to branch A as bug 123 (potentially as a
different user) then you still wont be able to see that the change was
by the same author, but you will be able to "see" that they are for the
same bug/change/job and then the defect tracking
system/bugzilla/whatever will show you who authored it, who tested, who
merged etc etc.

If this change would be valuable - please start a thread on the
support.cvsnt newsgroup on news.cvsnt.org and if there is enough
interest I can vote for it at our team meetings too.  Of course you'd
have to "upgrade" to CVSNT from CVS, but that's a seemless "in place"
operation.

Regards,


Arthur Barrett






reply via email to

[Prev in Thread] Current Thread [Next in Thread]