Bug 171488 – EWS bot can't apply patch for https://bugs.webkit.org/show_bug.cgi?id=171487

• Component: Tools / Tests
• Status: NEW

[Sam Weinig]

None of the EWS bots seem to be able to apply the patch I uploaded to https://bugs.webkit.org/show_bug.cgi?id=171487 using webkit-patch upload from a completely up-to-date tree.

[Sam Weinig]

Created attachment 308705 [details]
Test diff

It looks like perhaps the issue is removing directories with files in them.

I did the experiment of creating a small patch which removes the Source/bmalloc/Configurations directory.

Then, after reverting the change locally, I tried applying the patch using svn-apply. And got similar output to the issue being seen on the EWS bots:

:-) samweinig:.../WebKitSVN/OpenSource> svn-apply ~/Desktop/removeBmalloc.diff 
Parsed 8 diffs from patch file(s).
patching file Source/bmalloc/Configurations/Base.xcconfig
D         Source/bmalloc/Configurations/Base.xcconfig
patching file Source/bmalloc/Configurations/DebugRelease.xcconfig
D         Source/bmalloc/Configurations/DebugRelease.xcconfig
patching file Source/bmalloc/Configurations/bmalloc.xcconfig
D         Source/bmalloc/Configurations/bmalloc.xcconfig
patching file Source/bmalloc/Configurations/mbmalloc.xcconfig
D         Source/bmalloc/Configurations/mbmalloc.xcconfig
The next patch would delete the file Source/bmalloc/Configurations/Base.xcconfig,
which does not exist!  Applying it anyway.
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: Source/bmalloc/Configurations/Base.xcconfig
|===================================================================
|--- Source/bmalloc/Configurations/Base.xcconfig	(revision 216002)
|+++ Source/bmalloc/Configurations/Base.xcconfig	(nonexistent)
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored

[Sam Weinig]

I'm not seeing the same behavior for single file deletions.

[Alexey Proskuryakov]

Jonathan, is this a dupe of the known issues with svn-apply?

[Jonathan Bedard]

(In reply to Alexey Proskuryakov from comment #3)
> Jonathan, is this a dupe of the known issues with svn-apply?

Yes.  There are a few bugs tracking this, I created <dar://problem/29979811> to track these kinds of issues with SVN.

[Sam Weinig]

If this is known, what is the underlying issue? I could swear this used to work. Is it a change in WebKit's tools, or a change in SVN (or something else) that is causing it?

[Jonathan Bedard]

(In reply to Sam Weinig from comment #5)
> If this is known, what is the underlying issue? I could swear this used to
> work. Is it a change in WebKit's tools, or a change in SVN (or something
> else) that is causing it?

It's SVN 1.9 syntax.

[Sam Weinig]

(In reply to Jonathan Bedard from comment #6)
> (In reply to Sam Weinig from comment #5)
> > If this is known, what is the underlying issue? I could swear this used to
> > work. Is it a change in WebKit's tools, or a change in SVN (or something
> > else) that is causing it?
> 
> It's SVN 1.9 syntax.

Do you happen to know which aspect? Either way, I might take a stab at it. (Just need to find someone with an older SVN to compare against.

[Jonathan Bedard]

(In reply to Sam Weinig from comment #7)
> ...
> Do you happen to know which aspect? Either way, I might take a stab at it.
> (Just need to find someone with an older SVN to compare against.

Read through your attached diff, the issue is pretty obvious.  Essentially, the SVN command we use to diff the directory generates a diff for each file in SVN 1.9 (it didn't use to) and then we diff each file as well (which we need to do because SVN's diff doesn't contain properties, if memory serves).  The result is that svn-create-patch creates a diff with files removed twice.