[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Segmentation fault during diff generation

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 2 Sep 2014 14:05:31 +0200

> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: dinsdag 2 september 2014 13:45
> To: Bert Huijben
> Cc: 'Peter Galcik'; dev_at_subversion.apache.org
> Subject: Re: Segmentation fault during diff generation
>
> I (Julian Foad) wrote:
> > The attached brute-force patch seems to fix many of the cases where
> changelist
> > filtering was missing or wrong, but I don't much like it and haven't
> > properly tested it.
>
> So here, attached, is an implementation of the post-filtering approach.
This is
> implemented using a common filter for repos-WC and WC-WC diffs.
>
> >>  Personally I would wish we could just do the changelist filtering in
the
> >>  output layer, instead of in all the diff drivers separately... But the
> >>  current code doesn't properly guarantee access to the local working
copy
> >>  paths to do that kind of processing there.
> >>
> >>  In many cases it prefers to just pass something url like. (Not
necessary
> the
> >>  proper url)
> >
> > If filtering at the output layer is easier that's totally fine with me,
> > anything as long as it's simple and consistent.
>
> What do you think of the attached implementation?
>
> I gave it a try by hand. I can't claim to have tested it thoroughly.

I really like this approach.

I think we should commit it and improve from there. (I can't see why it
would be worse than the current/old code)

Good catch on missing a few skip implementations. The unified diff output
handler currently never sets these flags, while the merge handlers do. (But
we don't support driving the merge from these diff drivers yet)

Your filter could be a start of using those skip flags though...

        Bert
Received on 2014-09-02 14:06:02 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.