[darcs-devel] New Patch Format sticky spots
Ian Lynagh
igloo at earth.li
Sat Apr 22 12:26:20 PDT 2006
[replying to 2 messages in one]
On Sat, Apr 22, 2006 at 10:15:07AM -0700, Jason Dagit wrote:
>
> I found some time tonight to start implementing a different format for
> hunks. Very simple but meant to allow skipping over data.
>
> hunk <filename> <line#> <#bytes of old content> <#bytes new content>
> <dump of old lines><dump of new lines>
I don't know where in the list archives or bug trackers it is OTTOMH,
but what the new format should look like has been discussed before.
I think it looked something like
hunk <file> <byte#> <line#> <#old bytes> <#old lines> <#new bytes> <#new lines>
old:
<the old data>
new:
<the new data>
(#lines is probably length . filter ('\n' ==))
BICBW.
There was also a discussion about how to indicate that this is version 2
of the hunk patch type, but I don't remember the conclusion (or if there
was one).
> 1) How many bytes do line endings add to the length of the old or new
> content? Is it okay to assume line endings are exactly one byte in
> patches? I know this will hold in unix-land, but what about win32?
You should treat line endings compatibly with current darcs (which,
again OTTOMH, I think means exactly '\n').
> 2) Currently when using darcs interactively (in darcs record for
> example) what you see on the screen is a dump of what goes into the
> patch file. So the direct result of my new patch format is that the
> patch goes from being easily readable by humans to a bunch of garbage
> all lumped together.
The new format should probably be pretty-printed into something like the
current format when being shown to the user, if that's what you're
asking.
> My new hunk reading code is
> essentially:
>
> lines (take n s)
> where
> n = length in bytes of either old or new
> s = patch data as a Stringalike
Why are you calling lines? The point of the new format is that, for most
operations (all but pretty-printing?), it stays as a single string.
Thanks
Ian
More information about the darcs-devel
mailing list