Hi,
I have noticed an issue with the moved files - where RB is no longer
able to display the old diff once the source file is removed/renamed in
the trunk. The problematic file diffs have the header like this:
Index: /new-file-name
===================================================================
--- /original-file-name (working copy)
+++ /new-file-name (working copy)
Which is then interpreted by RB to mean a source revision of HEAD.
Obviously, once the file changes in HEAD (i.e. is renamed - or has
textual changes incompatible with the patch), the diff fails to apply.
What's worse is that such breakage is not immediately visible - as long
as the source file exists in trunk and does not have incompatible
changes, it shows the diff just fine.
I traced the generation of such header to SVN 1.7.x (probably, earlier
version also have the same problem). SVN 1.8.x displayes "(revision
XXXXX)" instead.
# Using SVN 1.7.18
$ svn cp foo bar
$ vi bar
$ svn di bar
Index: bar
===================================================================
--- bar (working copy)
+++ bar (working copy)
I think RBTools should detect if the SVN has reported "(working copy)"
as the source file revision and in that case, obtain the missing
revision from the 'svn info' output. The server probably needs to reject
the patch if the source file revision is invalid (to safe-guard against
older RBTools uploading such broken diffs). I could prepare the patch
for RBTools, if needed.
Another question is, how to recover the diffs already in RB. The
information recorded in a file diff is obviously insufficient to get
that revision number. There are two hints at the automated recovery, though:
- If the same source file was also deleted in this diff set, the
'deleted' part of the diff reports the revision of the source file.
Since it was the same source file - the revision can be copied to the
'copied+modified' part of the diff.
- If all the other files in the diff (which do not have PRE-CREATION as
the source revision) have the same source revision, I think it is more
or less safe to assume the problematic file also originated at the same
revision.
In any case, it would be helpful to have an 'rb-site' command to detect
and if possible, fix such issues.
Regards,
Alexey.
--
Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
---
Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
---
Happy user? Let us know at http://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
