You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@wandisco.com> on 2014/09/26 10:10:47 UTC
Re: svn commit: r1626023 - in /subversion/branches/move-tracking-2/subversion:
include/private/svn_editor3.h libsvn_delta/compat3.c libsvn_ra/ra_loader.c
libsvn_repos/commit.c libsvn_wc/util.c libsvn_wc/wc.h
On 18.09.2014 18:48, julianfoad@apache.org wrote:
> Author: julianfoad
> Date: Thu Sep 18 16:48:44 2014
> New Revision: 1626023
>
> URL: http://svn.apache.org/r1626023
> Log:
> On the 'move-tracking-2' branch: Simplify editor shim usage by passing file
> content in memory instead of in temporary files.
>
> The shim code was leaving temporary files in /tmp. Managing temporary files
> correctly (for example, cleaning up even in case of error) is difficult, and
> handling of text content too big to fit in memory is unnecessary at this
> stage of development.
This is why spillbufs exist, and why the serf push/pull adapter creates
tempfiles in .svn/tmp. Why don't you just use the same mechanism?
-- Brane
Re: svn commit: r1626023 - in /subversion/branches/move-tracking-2/subversion: include/private/svn_editor3.h libsvn_delta/compat3.c libsvn_ra/ra_loader.c libsvn_repos/commit.c libsvn_wc/util.c libsvn_wc/wc.h
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
>> URL: http://svn.apache.org/r1626023
>> Log:
>> On the 'move-tracking-2' branch: Simplify editor shim usage by passing file
>> content in memory instead of in temporary files.
>>
>> The shim code was leaving temporary files in /tmp. Managing temporary files
>> correctly (for example, cleaning up even in case of error) is difficult, and
>> handling of text content too big to fit in memory is unnecessary at this
>> stage of development.
>
> This is why spillbufs exist, and why the serf push/pull adapter creates
> tempfiles in .svn/tmp. Why don't you just use the same mechanism?
That occurred to me. For my purposes here the priority is ease of prototyping, and I'm more familiar with stringbuf semantics than with spillbuf. When we need release-quality code then presumably spillbuf is the way to go, I agree.
- Julian