Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Rebaselined file during review fails to show new baseline

Bela Lubkin
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 11, 2017

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<

1 answer

0 votes
Bela Lubkin
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 11, 2017

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...

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events