Summary: | Teach svn-apply and svn-unapply to use patch(1) for additions and deletions | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | David Kilzer (:ddkilzer) <ddkilzer> | ||||||
Component: | Tools / Tests | Assignee: | David Kilzer (:ddkilzer) <ddkilzer> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | darin | ||||||
Priority: | P2 | ||||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
David Kilzer (:ddkilzer)
2006-07-12 08:59:22 PDT
For my next trick (a different bug), I will make svn-apply and svn-unapply use the property change information in such patches to update properties when fed patches. Created attachment 9473 [details]
Patch v1
Most of the changes are self-explanitory.
The worst code is for reversing a deletion.
- We handle a local file existing (when one shouldn't) by renaming it to *.orig.
- We unapply the deletion (which creates the file), but we rename it to a temp file name before running svn revert in case the contents are the same.
- After we rename the temp file back to the original file name, we must work around a timestamp bug in Subversion where the svn client thinks the file hasn't change if its timestamp isn't sufficiently different.
Created attachment 9474 [details]
Patch to clean up "No newline" and "Property changes" droppings
This patch cleans up the "No newline" and "Property changes" text in various files that should not have been included when files were checked in.
Comment on attachment 9473 [details]
Patch v1
Looks good. r=me
Attachment 9473 [details] (Patch v1) committed as revision 15477. Attachment 9474 [details] (clean up) committed as revision 15478. |