The patch format as produced by "svn diff" is not perfect; in particular, it does not clearly describe changes which entirely delete existing files or which add brand-new files. For more background on the problem, read: http://svn.haxx.se/dev/archive-2004-09/0469.shtml

If the patch adds or deletes a file, this should have been mentioned explicitly by the developer when the patch was attached to the JIRA issue, and the output of "svn stat" should also have been attached to assist the committer and reviewers.

Here's how to apply a patch which includes adds and/or deletes:

  • apply the patch normally, using patch -p0
  • run svn status.
  • read the "svn stat" output from the JIRA issue, and take note of each file which is to be (A)dded or (D)eleted.

Newly added files will show up with ?, indicating that Subversion does not know anything about them. You will have to add these yourself using svn add.

You will have to set svn properties for added files. In particular for all text files. Run svn propset svn:eol-style native FILE(S). If you have your subversion configuration setting this should be done automatically. Add this list to your ~/.subversion/config file, as described in http://www.apache.org/dev/version-control.html. Do not automatically take for granted the properties in the contributor's patch file, he/she may have got it wrong; use your own judgement.

Now compare your sandbox to the contributor's: run svn status | diff - CONTRIBUTOR'S_SVN_STATUS_FILE. This should be clean, except that the ordering may be different. You can overcome this by sorting both your own svn status output and the contributor's file with sort before comparing: svn status | sort > MY_SVN_STATUS_FILE; cat CONTRIBUTOR'S_SVN_STATUS_FILE | sort | diff - MY_SVN_STATUS_FILE.

  • If the svn status output was made on Windows vs. Unix, you may need to adjust formatting such as spacing and forward versus backward slashes.
  • If the diff contains new, empty files, patch will not create them for you; you will have to create them yourself using touch FILENAME.
    • After creating such new, empty files, you will have to add them, too, with svn add.

For a file which was supposed to be deleted, svn revert the file to undo the changes made by patch, then issue svn delete to mark the file for deletion.

When you think you are done, issue "svn stat" on your sandbox, and compare the results against the output attached to the JIRA issue.

Example: deleting a test file

You can perform an svn delete in your own workspace. It only deletes the files locally. Doing this will ensure that an svn stat shows the files as deleted and thus tells the committers what needs to be deleted.

In addition to deleting the obvious files you would need to remove FILENAME.java from any suite file it is in (.runall file). You also need to then run derbyall just to double check that no other test is relying on that class. So the steps to removing an old test are:

  1. Remove (svn delete) the test file (.java or .sql) and any support files it has like test_app.properties. 2. Remove (svn delete) any master files for that test 3. Remove the test from any suite (.runall file) it is in. 4. ant clobber ; ant all (check no build failures) 5. run derbyall - check for no (new) failures 6. svn diff to create a patch & attach to the jira issue along with the output of svn stat
  • No labels