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

Re: [Patch] configure.in and GNU diff/patch (was Re: r727 doesn't build w/ --disable-shared)

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-01-09 03:38:44 CET

On Tue, Jan 08, 2002 at 09:36:22PM -0500, Garrett Rooney wrote:
> On Tue, Jan 08, 2002 at 07:59:49PM -0500, Garrett Rooney wrote:
>
> > > > now the question is what to do about it. i have a patch that will
> > > > just handle this for SVN_CLIENT_DIFF. we can just check that diff
> > > > exited with either 0, 1, or 2 (the only exit codes it is supposed to
> > > > use, according to it's man page), and if it exits with something else,
> > > > we know there's a problem and we error out.
> > > >
> > > +1 for this approach. We should also be doing something similar when we run
> > > patch. In fact I beleive there are/were comments to the effect of
> > >
> > > /* ### need to do better handling of the exit status diff left us here. */
> >
> > ok, i'll put that patch together again and send it off as soon as the
> > recent diff breakage is fixed (no reason to send the patch and then
> > imediately have to recreate it if any of the files change...).
>
> here's the diff to handle errors calling diff. i looked for places
> that we're calling patch, but the only place we seem to use
> SVN_CLIENT_PATCH is in libsvn_wc/get-editor.c, and that's just
> creating a stringbuf. i couldn't find anywhere that we actually call
> it.

oh, and i forgot to mention, i was going to write a regression test
for this, but i can't think of a way to test it without actually
removing the diff binary or compiling a whole nother version of svn...
if anyone has a good idea of how to test this case, i'm all ears.

-garrett

-- 
garrett rooney                     Unix was not designed to stop you from 
rooneg@electricjellyfish.net       doing stupid things, because that would  
http://electricjellyfish.net/      stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:55 2006

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.