[PATCH 5 of 6] patch: add mempatching support
Augie Fackler
durin42 at gmail.com
Mon Apr 19 20:46:05 CDT 2010
On Apr 19, 2010, at 8:44 PM, Steve Borho wrote:
> On Mon, Apr 19, 2010 at 8:25 PM, Augie Fackler <durin42 at gmail.com>
> wrote:
>>
>> On Apr 19, 2010, at 7:26 PM, Bill Barry wrote:
>>
>>> Awesome!!!
>>> /me looks forward to hg 1.6
>>>
>>> Augie Fackler wrote:
>>>>
>>>> + def readlines(self, fname):
>>>> + if fname not in self.parentctx:
>>>> + raise IOError(errno.ENOENT, 'Cannot find %r to
>>>> patch' %
>>>> fname)
>>>> + # TODO(durin42): refactor so we can skip StringIO here
>>>> + lr =
>>>> linereader(cStringIO.StringIO(self.parentctx[fname].data()),
>>>> + self.eolmode != 'strict')
>>>> + self.eol = lr.eol
>>>> + return list(lr)
>>>
>>> What do you mean with this TODO (perhaps I am not understanding
>>> bits of
>>> the code here)? I am trying to understand what can be refactored
>>> so that the
>>> instantiation can be skipped (self.parentctx[fname].data() is a
>>> byte array
>>> isn't it?).
>>
>> Yes, it's a byte array, but there are other things depending on it
>> being
>> file-like right now (as far as I could tell). I wanted to get these
>> patches
>> done so I could try and do some cleanup in patch.py later.
>>
>>>> +def memapplydiff(ui, fp, ctx, strip=1, eolmode='strict'):
>>>> + """Apply a diff in memory to ctx.
>>>> +
>>>> + If the diff doesn't apply cleanly, this will raise a
>>>> PatchError,
>>>> + since reject files can't be sanely written.
>>>> + """
>>>>
>>> What affect would this have on some potential future integration
>>> with a
>>> wiggle type program?
>>
>> Not sure what you mean by a "wiggle" type program.
>
> wiggle was a pre-cursor to mpatch; a fallback algorithm for patch
> hunks that fail to apply.
Should be fairly doable with the refactoring done in patch 3 - that
makes it much easier to hack in new patchers. Maybe memapplydiff
should even take a patcher class as a kwarg so one can plug in
alternate strategies at runtime without monkeypatches.
>
> --
> Steve Borho
More information about the Mercurial-devel
mailing list