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

Re: svn commit: r940786 - in /subversion/trunk/subversion: include/svn_client.h libsvn_client/patch.c svn/patch-cmd.c tests/libsvn_client/client-test.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 4 May 2010 12:59:27 +0200

On Tue, May 04, 2010 at 11:36:49AM +0100, Julian Foad wrote:
> Wasn't the idea that the caller could choose whether the patched result
> should be written straight to the target file or to somewhere else?

No, that wasn't the idea.

The patched result is *always* written to tempfiles first. Always has been.
It is never written "straight to the target file" while being computed.

Rather, the target file is eventually overwritten with the tempfile,
resulting in the application of the patched result to the working copy.

(This is of course an implementation detail, but should be understood
when reasoning about the patch code itself. Callers don't need to care
how it is done.)

The caller can suppress the application of the patched result to the
working copy by passing dry_run == TRUE.

The idea behind the mechanism to retrieve the tempfiles is that
applications like TortoiseSVN can pass dry_run == TRUE and look at the
tempfiles to see what the patched result will look like.

Passing the request for access to the tempfiles alone does not imply
dry_run == TRUE, but the primary use case is the dry_run == TRUE case.
If dry_run == FALSE is passed, the working copy will be patched and the caller
will have access to the tempfiles which replaced files in the working
copy (and it's the caller's job to clean them up) -- not very exiting :)

Received on 2010-05-04 13:00:05 CEST

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