[webkit-reviews] review requested: [Bug 12023] svn-create-patch and friends should handle moved/copied files : [Attachment 12139] Patch v2

[bugzilla-request-daemon at macosforge.org]

David Kilzer (ddkilzer) <ddkilzer at webkit.org> has asked  for review:
Bug 12023: svn-create-patch and friends should handle moved/copied files
http://bugs.webkit.org/show_bug.cgi?id=12023

Attachment 12139: Patch v2
http://bugs.webkit.org/attachment.cgi?id=12139&action=edit

------- Additional Comments from David Kilzer (ddkilzer) <ddkilzer at webkit.org>
This patch includes changes for svn-apply and svn-unapply, and fixes the issue
of missing removed file patches mentioned in Comment #2.

Theory of operation:

In subversion, a moved (or renamed) file is identical to a copy and a delete,
so the modified patch only needs to identify the special case when an added
file was copied from an existing file.

The subtle difference introduced to identify copied files is a modified "from"
line (the patch line that starts with "--- ") that references the original path
and revision number instead of the new path.

Thus an svn copy will generate up to two patches:  one for the copy and one for
any changes made after the copy.  An svn move (or svn rename) will generate up
to three patches:  one for the delete, one for the copy, and one for any
post-copy changes.

Compatibility issues with plain old patch(1):

- In POSIX mode, patch(1) determines the file name to patch by checking for the
existence of the first path in this list:  old ("--- " line), new ("+++ " line)
and index ("Index: " line).  Because svn-create-patch now modifies the old line
to point to the original file, patch(1) wants to patch the wrong file (and ends
up doing nothing because that file already exists).  In "normal" mode (-n),
patch(1) completely ignores a patch formatted this way.

- If changes are made after a file is copied or moved, svn-create-patch will
create two patches:  one to represent the copy and one to represent post-copy
changes.  When using patch(1) to reverse the change, these patches must be
applied in the reverse order as well (although I don't think patch(1) applies
the patches in a file in reverse order).  Assuming the previous issue was
resolved, this issue would still remain.