[Webkit-unassigned] [Bug 9299] Teach svn-create-patch and friends to work with binary files

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=9299


ddkilzer at kilzer.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|ddkilzer at kilzer.net         |webkit-
                   |                            |unassigned at opendarwin.org
             Status|ASSIGNED                    |NEW




------- Comment #2 from ddkilzer at kilzer.net  2006-06-04 04:14 PDT -------
Reassigning back to webkit-unassigned for a wider audience.

(In reply to comment #1)
> Created an attachment (id=8686)
 --> (http://bugzilla.opendarwin.org/attachment.cgi?id=8686&action=view) [edit]
> Patch v1

Random design decision information:

One downside to setting the binary file contents this way (e.g., relying on the
presence or absence of the base64-encoded chunk of text) is that any "old"
patches which include patch segments for added or modified binary files will
actually look like deletions.  The additions will fail out, but the
modifications will work as if they were deletions.  I'd have to add extra
contextual information with the chunk o' text to keep this from happening.

I also thought about putting some kind of markers around the chunks o' text,
but couldn't decide whether to go old-style with uuencode-like begin/end lines,
or new-style with MIME delimiters.  Once I figured out that I could just use a
regex to pull it back out, I skipped the markers for the first patch.

Note that the other nice thing about simply adding the chunks o' text in with
the binary patches is that this format will degrade gracefully for anyone using
just the patch(1) command.  The patch(1) command is smart enough to ignore
content that isn't a patch, so it will simply skip the chunks o' text when it
runs into them.

Another downside to including the chunks o' text inline with each binary patch
is that it will make it harder to review a patch simply by looking at it if the
images are interspersed with the text file changes.  This could be fixed by
sorting all of the binary patches to the end in svn-create-patch.

I also thought about trying to compress binary files before base64-encoding
them, but I couldn't come up with a nice way to communicate this information
(that all of the binary files are also compressed) to someone who saw the
format for the first time, was familiar with plain diff(1) output, but wanted
to grok the new format through trial-and-error.  I suppose the file(1) command
could help them determine that the base64-decoded text was compressed by a
particular program, though.  It's trivial to add gzip or bzip2 compression
before base64-encoding.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.