You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2009/10/29 10:57:35 UTC
[PATCH] Merge was leaving temp files behind
This patch stops merge from leaving temp files behind in, for example,
merge_tests.py 41.
As the fix is adding a "delete on pool cleanup" flag, I'd appreciate a
second pair of eyes to confirm that's reasonable in terms of pool
lifetime issues.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412549
Re: [PATCH] Merge was leaving temp files behind
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Every now and again a little nugget of humour, like this, comes along
and gives me a little giggle!
Gavin.
On 30/10/2009, at 01:10 , Stefan Sperling wrote:
> On Thu, Oct 29, 2009 at 11:57:35AM +0100, Julian Foad wrote:
>> This patch stops merge from leaving temp files behind in, for
>> example,
>> merge_tests.py 41.
>>
>> As the fix is adding a "delete on pool cleanup" flag, I'd
>> appreciate a
>> second pair of eyes to confirm that's reasonable in terms of pool
>> lifetime issues.
>
> Julian and I discussed this further using an ancient but high-bandwith
> communication protocol that's only possible if both end points are
> geographically located in the same room.
>
> See r40277.
>
> Stefan
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412653
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412870
Re: [PATCH] Merge was leaving temp files behind
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Oct 29, 2009 at 11:57:35AM +0100, Julian Foad wrote:
> This patch stops merge from leaving temp files behind in, for example,
> merge_tests.py 41.
>
> As the fix is adding a "delete on pool cleanup" flag, I'd appreciate a
> second pair of eyes to confirm that's reasonable in terms of pool
> lifetime issues.
Julian and I discussed this further using an ancient but high-bandwith
communication protocol that's only possible if both end points are
geographically located in the same room.
See r40277.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412653