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

Re: svn commit: r983766 - /subversion/branches/performance/subversion/libsvn_client/export.c

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Fri, 13 Aug 2010 01:42:16 +0200

Daniel Shahaf wrote:
> Stefan Fuhrmann wrote on Thu, Aug 12, 2010 at 22:08:03 +0200:
>> Hyrum K. Wright wrote:
>>> On Tue, Aug 10, 2010 at 5:56 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>>>> On Mon, Aug 09, 2010 at 09:45:18PM +0300, Daniel Shahaf wrote:
>>>>> Also, this isn't really related to performance; it belongs on /trunk. Next
>>>>> time, you could send this with a [PATCH] marker in the subject line, and
>>>>> a full committer could +1 you to commit that to directly to /trunk.
>>>> Yes, please send patches if you have a change that isn't direclty
>>>> related to your performance improvements work.
>>>> The scope of the branch is not "stefan2 makes all of his commits there",
>>>> it's "this branch is for stefan2's performance-related work".
>> This was a special case because without the patch, my load
>> tests wouldn't run. So, I could at least kind of justify the process
>> violation to myself as "performance-related work".
>> Sure, but we still want to get the patch in trunk one way or another (and
>> before the whole branch is merged). Just committing it to the branch and
>> forgetting about it doesn't solve the problem :-)
Point taken ;)
> Speaking of which: what's the plan for merging the branch to trunk? i.e.,
> it's great to see you working there and making progress, but we all would
> like to see that in 1.7 (or, at least, 1.8)...
I'm still in the process of copying changes from my prototype source
to the performance branch. Commit-count-wise, I might be half through
the pile. The most expensive changes, those requiring large amounts of
commentary or touch many, many file, should be in the SVN repo by now.
The whole synchronization process is the reason why my patches arrive
in a seemingly arbitrary order - it is determined by the manageability of
the diff tool(s).

So, my hope is that all essential changes are in by the end of this month,
including some basic tests for the new classes I introduced.

Basically, my whole motivation for all that work is to have it in 1.7 so
I can have it rolled out in my company for the next "infrastructure cycle".
If that would mean to leave some smaller parts out, I would rather go
for that part I can get than waiting a long time for the whole thing.

-- Stefan^2.
Received on 2010-08-13 01:42:55 CEST

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.