[Webkit-unassigned] [Bug 14590] svn-create-patch fails when svn mv is used on directory trees

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=14590





--- Comment #8 from David Kilzer (ddkilzer) <ddkilzer at webkit.org>  2009-11-04 13:16:24 PDT ---
(In reply to comment #7)
> If we make svn-create-patch mimic what git does, then we'd have a series of
> rename patches for each file (although svn-create-patch does those
> differently--it puts a full delete and a full add patch in for each file, plus
> a third patch if the source was changed after the move).  However, you still
> have to have some logic in svn-apply (and svn-unapply) that can figure out that
> we renamed an entire directory before it applies the individual patches.
> 
> One approach would be to add a special patch entry (similar to a property
> change "patch", except it would denote directory moves/renames) that does
> nothing when used with patch(1), but provides a hint to svn-apply and
> svn-unapply that whole directories were renamed or moved.  Then we could
> "ignore" the whole-file-delete and whole-file-add patches and only apply the
> "changes-after-move" patch for any given file under that directory.

BTW, the reason the "whole-file-delete" and "whole-file-add" patches (followed
optionally by a "changes-after-move" patch) are included in the output of
svn-create-patch was so that if you don't have svn-apply available, you have
some chance of still using the patch file with the patch(1) command.

In practice, patch(1) sometimes chokes when it has a patch that creates a new
file, followed immediately by a second patch that changes that file.  (I just
tried it on Snow Leopard and my test patch applied without any issues, so maybe
this issue was fixed or I misremembered the problem.)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.