How do I get a diff of an issue in Accurev without any inherited changes?

Question

While I'm not sure I have a satisfactory answer on my other Accurev question, I believe I'm starting to understand the issue I'm seeing with Accurev diffs.

The flow is something like this:

1. Developer A makes some changes for bug 1, promote.
2. Developer A makes some changes for bug 2, promote.
3. Developer B reviews Developer A's changes for bug 1 and sends it back for further changes.
4. Developer C reviews Developer A's changes for bug 2 and approves it, additional promotion.
5. Developer A makes more changes for bug 1, promote.
6. Developer C reviews Developer A's changes for bug 1.

The last step is where I perceive the breakage. Developer C cannot, in any rational way, see all the changes related to bug 1, even though every transaction/version (whatever Accurev calls them) is associated with that issue id.

If I do diff against basis I get all of the bug 2 changes as well as everything else that's been promoted. Multiply that times 30 developers and it's a nightmare.

It gets real messy if there were overlaps and merge resolution, but lets assume, for the moment, that attribution doesn't get wrong except in that case... even if I have seen it do otherwise, it might just be a misunderstanding.

Anyway, assuming that all promotes were "clean" and (as I understand them) new transactions are "alias" transactions of each developers "keep" transactions.

How do I view combined diffs of the two transactions?

Specifically the transactions in step 1 and step 5 above. There will be two transactions, and I want only the changes made in those transactions and only those transactions. Ideally, a nicely formatted or GUI tool diff that works recursively (not on individual files, the whole thing).

Note, valid answers may be "You're doing it wrong," but should include constructive suggestions of what to change such as "Do your reviews in the developer's workspace," or similar. I suspect we might just be using it wrong.

Answer 1

I believe that there's no way to view a given developer's changes to a file, after those changes have been promoted when there are multiple sets of changes for that file.

Diff against backed has no meaning in a parent, non-workspace stream.

Diff against basis has everyone's changes.

See the comments on the accepted answer of What is the difference between basis and backing in Accurev.

Answer 2

I wouldn't say you're doing it wrong, but there are definitely some assumptions that have to be made here. For my part, it seems from your description that you're clearly using a single file in the example (to simplify, anyway) and that the changes are made serially.

In AccuRev, a Change Package contains the context of any file associated with the "bug" from the basis to the head. So when the developer fixed Bug 1, the "beginning" and "end" version of the file are attributed to Bug 1. Regardless of what any of the other 30 developers do at this point, you can always view the Change Package for Bug 1, look at the changes tab, and diff the file only as it pertains to that bug, even if a thousand additional changes are promoted into that stream.

Where the difficulty arises is in the fact that the developer assumed he was done, made subsequent changes to the file that was part of Bug 1, linked that to Bug 2, and moved on. When the review is done and he has to now make additional changes for Bug 1, those are being built on top of the Bug 2 changes.

First of all, AccuRev won't let you promote and link that file to Bug 1 without you choosing to do a "Change Package Merge". This means that there is a gap in the attribution of the versions to the specific bug you want to link to - specifically the changes to Bug 2. AccuRev wants you to confirm that those Bug 2 changes are okay to be implicitly included in the Bug 1 fix. So we won't let it happen just by accident. However, if you decide that you don't want the Bug 2 changes to be present in the Bug 1 content, you have to do some patching. This gets trickier under the workflow you've described, but definitely possible. The bottom line is that the scenario you've presented is one in which no tool is going to be able to automatically handle because there are serial changes associated with different bugs. Well, let me amend that and say that no tool which works outside of things like "check in comments" and provides automated ways to work at the issue level instead of the file level will. The AccuRev Change Package is very powerful and puts the control in your hands, allowing you to operate on the CP as an object all throughout the development process.

I hope this answers your question as thoroughly as possible in this forum. If you have additional questions or want to discuss in more depth, we can arrange that as well.

Cheers,
~James