Rebaselined file during review fails to show new baseline
Asked by 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\<


Answers:
author: Bela Lubkin
body: I did see ['Pre-commit iterative reviews on Crucible (SVN) with patches that can each be compared to baseline?'](https://community.atlassian.com/t5/_/_/qaq-p/617577 "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...


Tags: svn