: Personally, never tried svn patch. Yeah ... i think it has some explicit assumptions about the patch file being generated by "svn diff" so it can use some of the header bits to know when files mentioned in a patch should be "svn rm", "svn mv", or "svn add"
In particular, if you note that files that are going wonky for you, it's the newly added files -- and in the git diff the "old" version of those files are refered to as "/dev/null". in an equivilent "svn diff" generated patch file the true path would be used. : # for git patches (maybe out of date) : patch -p1 --merge < patch.txt ...which works fine for your patch (although i personally don't mind hte reject files) ... hossman@frisbee:~/lucene/dev$ curl https://github.com/apache/lucene-solr/pull/18.diff | patch -p1 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 8196 100 8196 0 0 9138 0 --:--:-- --:--:-- --:--:-- 14034 patching file solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java patching file solr/core/src/test-files/solr/analysisconfs/analysis-err-schema.xml patching file solr/core/src/test/org/apache/solr/analysis/ThrowingMockTokenFilterFactory.java patching file solr/core/src/test/org/apache/solr/update/AnalysisErrorHandlingTest.java hossman@frisbee:~/lucene/dev$ svn status ? solr/core/src/test/org/apache/solr/update/AnalysisErrorHandlingTest.java ? solr/core/src/test/org/apache/solr/analysis/ThrowingMockTokenFilterFactory.java ? solr/core/src/test-files/solr/analysisconfs M solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
