[Webkit-unassigned] [Bug 14590] svn-create-patch fails when svn mv is used on directory trees
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Jul 14 13:11:56 PDT 2007
http://bugs.webkit.org/show_bug.cgi?id=14590
ddkilzer at webkit.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ddkilzer at webkit.org
Summary|svn-create-patch fails when |svn-create-patch fails when
|svn mv was used |svn mv is used on directory
| |trees
------- Comment #3 from ddkilzer at webkit.org 2007-07-14 13:11 PDT -------
How do you propose handling moved (or copied) directories in svn-create-patch
(and svn-apply and svn-unapply)?
Handling copied/moved files was fixed in r18513 (Bug 12023) by doing the
following:
- For files created by 'svn cp', extra information was added to the patch (in a
way that plain old patch(1) would ignore) that svn-apply and svn-unapply read
and "do the right thing" with. This generates a single 'add file' patch.
- For files created by 'svn mv', the extra information is added in the same way
as 'svn cp'. Two patches get created: one to add the moved file (with the
extra info), and one to delete the old file.
- In the special case where the moved or copied file also had local
modifications, a *third* patch is created (after the initial add) which
captures the local changes.
http://trac.webkit.org/projects/webkit/changeset/18513
For moved or copied directories, I see two approaches:
1. For each file in the moved/copied directory hierarchy, do the same thing for
an individual moved/copied file. Then svn-appy and svn-unapply would have to
"recognize" that an entire directory tree had changed.
2. Come up with a way to describe the directory tree move/copy so that patch(1)
would ignore it, but svn-appy and svn-unapply would handle it properly.
Any ideas or suggestions?
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list