Rebaselined file during review fails to show new baseline

[Bela Lubkin]

We use Subversion, JIRA, FishEye & Crucible. My command-line svn client is 1.9.3; svn server 1.8.10; JIRA 7.3.6; FishEye & Crucible 4.4.0

I have a changeset in progress, with changes to 7 files. Here is a timeline of actions (A%d) and behaviors / bugs observed (B%d):

A1. svn update (my tree is now sync'd to revision 249367; one file, which I will call 'edited-file.py', was last changed at revision 249294)
A2. edit my files
A3. svn diff > diff1
A4. start a review using 'pre-commit, upload diff' in the FishEye web interface
A5. edit some more, svn diff > diff2, upload this diff to the review (attached to diff1)
A6. edit some more, svn diff > diff3, upload this diff to the review (attached to diff1)
A7. svn update (tree now sync'd to 249433); this includes commit 249390, which changes the baseline of edited-file.py. The changes were non-conflicting with mine.
A8. svn diff > diff4, upload this diff to the review (attached to diff1). Note that edited-file.py was *NOT* edited by me between diff3 and diff4; it was changed only due to merging-in of 249390 by `svn update`.

At A8, I expected the FishEye timeline for edited-file.py to look like:

249294 -- iteration #1 -- iteration #2 -- iteration #3 -- 249390 -- iteration #4

B9: 249390 did not appear in the timeline; only iterations 1..4. Dragging the diff-between endpoints on the timeline showed diffs as if commit 249390 had never happened. The dragged-to diff between 249294 and iteration #4 was what I would have expected to see between 249294 and iteration #3. (I did not at that time look at the 249294-#3 diff, and things have been changed since then.)

A10. I re-uploaded diff4, this time *not* attaching it to the diff1 series (so at this point diff4 has been uploaded twice, once attached and once not).

At A10, the timeline for edited-file.py under the diff1 series on the left-hand side as as above. The timeline under the diff4 series was:

249390 -- iteration #1

A11. I tried to uncheck all of the diffs in the diff1 series so that reviewers would know that only diff4 was in action. But as there were comments on edited-file.py, I was only able to uncheck diff[234] but not diff1 in that series.

A12. In describing the B9 misbehavior, I later re-checked all the diffs in the diff1 series.

B13: 249390 still did not appear in the timeline. As at A8, the appearance of the timeline was:

249294 -- iteration #1 -- iteration #2 -- iteration #3 -- iteration #4

without any notice of the new baseline. HOWEVER, now when dragging the diff poles farthest apart, it now shows the changes introduced in 249390 (as if they were something I were adding).

To be clear: at A8, the dragged diff [249294-iteration #4] had the appearance I would have expected for [249294-iteration #3], without the changes in 249390. At A12, [249294-iteration #4] now had the expected appearance, including the changes from 249390. In neither case did 249390 appear as a selectable or visible point on the timeline. But it did appear on the timeline of the separately uploaded diff4-only series.

After the actions A11, A12, I can no longer reproduce misbehavior B9. B13 (i.e.: lack of 2nd baseline revision on timeline) is still present.

The actual source / diffs are proprietary and cannot be shown.

I have not tried to reproduce the sequence and am not sure I could. It's quite likely I've forgotten some details. I searched somewhat in this 'questions' department as well as in the CRUC JIRA, but didn't successfully narrow either search to what I imagine has probably been reported before...

Thanks,

>Bela<

[Bela Lubkin]

I did see 'Pre-commit iterative reviews on Crucible (SVN) with patches that can each be compared to baseline?' which sounds likely to be the same underlying bug / misbehavior.  But it has no response so that's not helpful...