2159: when there are other commits meanwhile, they show up in delta-diffs

o3s****@gmai***** (Google Code) (Is this you? Claim this profile.)
July 1, 2011
311
RBVersion:1.5.5; Subversion Repository

What steps will reproduce the problem?
1. Edit something, create a review.
2. Edit something more, upload another diff to that review
3. Edit something in another workingcopy, commit it; same files as some of the edits above, no conflicting changes to your other edits.
4. Update the working copy with the edits (-> no conflict...) 
5. Edit something more in the first working copy, upload another diff to that review.
6. Now view the incremental diff r2->r3
7. you will also find the commits done meanwhile in the changeset highlighted.

What is the expected output? What do you see instead?
Only changes uploaded with patches should be shown.
david
#1 david
There's nothing we can do here. If you need to avoid this, the best way is to avoid syncing before you post your r3 diff.
#2 o3s****@gmai***** (Google Code) (Is this you? Claim this profile.)
hm, we don't "sync" since we use it on an SVN backend; and as other work goes on SVN marches forward.

and even using git or something else, stopping to work on other topics (so... post new reviews where you need newer revisions as base for?) isn't a real option.

Shouldn't the solution be that reviewboard remembers the actual revision at the post of r1 for its ongoing work, and base on this to create its new delta diffs?
david
#3 david
The problem is that if a new revision of the diff comes off a different revision of the code, there's no way for us to know if it'll apply cleanly on top of what r1 was based on (and if the files themselves have changed in between, where you're seeing changes in the interdiff, it probably won't).

What I mean about making sure you don't sync is that you base your updated diff off the same revision of the code as the first revision. With svn you can do this by updating your checkout to that revision (svn update -r <rev>), and with git you can just avoid rebasing your branch, and then post-review with --parent set to the parent of the change (assuming master has been updated).