Re: svn commit: r26761 - in branches/svnpatch-diff/subversion: include libsvn_client libsvn_subr svn tests/cmdline

"David Glasser" <glasser@davidglasser.net> writes:

> that way to me. Also, I don't really understand from this
> documentation what exactly the outfile and errfile parameters are for:
> they collect the output of the patch(1) invocation? svn_client_patch
> doesn't parse that itself?

There's no way we can reliably parse it.

> (Also, I'm not sure how appropriate it is
> to refer to the '--patch-cmd' CLI argument in the API docs.

I think it is not at all appropriate.

> > + /* Posix convention. */
> > + patch_cmd_args[0] = patch_cmd;
> > + patch_cmd_args[1] = NULL;
>
> Huh, I expected that you would have needed some sort of -p argument to
> patch.

GNU patch stupidly always requires a -p option, so probably this
needs -p0 here. Perhaps cacknin is testing on a BSD system,
where patch is not so stupid?

Also, which POSIX convention? patch is certainly not in POSIX.

> > + /* This is where we have to make the assumption that if the exitcode
> > + * isn't 0 nor 1 then the external program got into trouble or wasn't
> > + * even executed--command not found (see below). Basically we're
> > + * trying to stick with patch(1) behaviour as stated in the man page:
> > + * "patch's exit status is 0 if all hunks are applied successfully, 1
> > + * if some hunks cannot be applied, and 2 if there is more serious
> > + * trouble." */
>
> Why is exitcode == 1 not any sort of error?

0 means all hunks applied successfully, 1 means some hunks
applied successfully, and >1 means something went wrong.

I have not really reviewed any of this svnpatch work yet, but as
I was scanning commit mails, the exitcode thing caught my eye.
Reviewing and testing this branch is on my todo list.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 29 02:00:38 2007