78: New Review Request: Subversion diff's don't work using the svn:// protocol

sam***@gmai***** (Google Code) (Is this you? Claim this profile.)
July 3, 2007 
What's the URL of the page containing the problem?


What steps will reproduce the problem?
1. Create a unified diff of a changeset.
2. Create a new review request set the base path to either
"whatever/your/path" or "svn://server/whatever/your/path" (neither way
seems to have an effect)
3. Upload the diff and create the review. The review creates successfully
but when trying to view the diff, nothing appears except the text:

"The patch to 'svn://server/whatever/your/path/some_file.py' didn't apply
cleanly. `patch` returned: patching file /tmp/tmpf4OfSj Hunk #1 FAILED at
12. Hunk #2 FAILED at 116. 2 out of 2 hunks FAILED -- saving rejects to
file /tmp/tmpf4OfSj-new.rej"

What is the expected output? What do you see instead?

Expected output is a view of the diff (I was able to get it to work on an
http:// repository, I think this is what's causing the problem)

What operating system are you using? What browser?

Review Board is installed on an Ubuntu Feisty system with the latest stable
version of Django (0.96).
chipx86
#1 chipx86
  • -Priority-Medium
    +Priority-High
    +Component-SCMTools
chipx86
#2 chipx86 
Just to be clear, the SVN server in question was set up to be accessed with svn:// in
both the server and in the repository configuration?

It sounds like a configuration issue. The tool makes no distinction between svn and
http URLs, and neither should the module we're using to talk to SVN. So I just want
to verify all this. Do you happen to have an SVN server set up that I can play against?
#3 benjamin********@gmai***** (Google Code) (Is this you? Claim this profile.) 
For what it's worth, I've had the same issue since the initial release of
ReviewBoard. Same error with svn://, http:// worked fine. This is on OS X with Django
svn and Python 2.4.
#4 email.*******@gmai***** (Google Code) (Is this you? Claim this profile.) 
Well, I'm having the same problem (patch not applying) and found out that, at least
in my case, it is because the files in the repository have CRLF line endings. If I
change the repository file to have LF line endings and redo the same changes, the
diff is shown.

I tried to follow the code (I don't know python) and saw that you are processing the
patch file. I think this processing is stripping the CR from the patch as the patch
is stored in the DB with no CR, and that mangled patch does not apply to the
repository file.

Hope this helps
#5 benjamin********@gmai***** (Google Code) (Is this you? Claim this profile.) 
email.do.nuno's got it. The svn:/http: issue is a red-herring for CRLF issues.
#6 email.*******@gmai***** (Google Code) (Is this you? Claim this profile.) 
Attached is a patch that fixes this, at least for me.

Nuno
#7 email.*******@gmai***** (Google Code) (Is this you? Claim this profile.) 
An identical patch was already committed to trunk as a result of review 85. However,
it is not enough, at least when using subversion.

Using a diff created with CRLF and reviewboard running on Linux, the revision info
gets an extra CR and fails to parse. I'm attaching a patch that removes them at
diffviewer's parser so that there is no need to change all SCM tools.

By the way, is there any way to invalidate patches on google code's interface? The
one named work-with-crlf.patch is obsolete.
chipx86
#8 chipx86
  • +Fixed