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:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 9:09 PM To: Yves Martin; [email protected]; 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
