On 22/05/12 21:07, Philip Martin wrote:
Julian Foad writes:
Hi Philip. Usually to reproduce a bug we only need to look as far as
the first time something goes wrong. I assume you have a specific
reason in this case for thinking that the information about whether a
*second* sync also
> -Original Message-
> From: Paul Burba [mailto:ptbu...@gmail.com]
> Sent: donderdag 24 mei 2012 0:43
> To: Subversion Development
> Subject: [PATCH]: Speed up deletion of multiple files
>
> On one CollabNet's forums a user reported that a single delete command
> of 2000+ WC files took w
On one CollabNet's forums a user reported that a single delete command
of 2000+ WC files took well over three hours to complete with 1.7.5
(see
http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=456214).
I'm able to replicate similar behavior with a partial checkout of
^/
On Wed, May 23, 2012 at 8:53 AM, wrote:
> Author: rhuijben
> Date: Wed May 23 12:53:10 2012
> New Revision: 1341848
>
> URL: http://svn.apache.org/viewvc?rev=1341848&view=rev
> Log:
> Help the Sqlite query planner a bit by rewriting two queries in a way that
> makes it use indexes, where it didn'
On May 23, 2012 8:53 AM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/wc-queries.sql Wed May 23
12:53:10 2012
>...
> @@ -995,6 +1000,7 @@ SELECT local_relpath, kind, repos_id, de
> FROM externals
> LEFT OUTER JOIN repository ON repository.id = externals.repos_id
> WHERE wc_id = ?1
>
Hi Stefan.
I'm just about starting to get the idea that I think you're talking about, but
I'm still having a hard time seeing how a state machine in the library would
need more than one state transition for any chosen resolution, or why it would
need to control information-display requests.
I
While thinking about "symmetric merge", it occurred to me recently that the
existing "sync" and "reintegrate" merges can already be used to achieve
to-and-fro merging between a pair of branches, without needing and keep-alive
dance [1] or other measures. This behaviour seems to be something tha
Greg Stein wrote:
> Branko Čibej wrote:
>> I'd really like to see you explain why this change of yours (33 ->
>> 33^4) is relevant in practice. It's not at all clear that this
>> multiplier gives a better key distribution than the time-honoured 33.
>
> Actually, there are some reasoned/studied
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: woensdag 23 mei 2012 4:54
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1341715 - in /subversion/trunk/subversion:
> libsvn_wc/wc-queries.sql libsvn_wc/wc_db.c
tests/libsvn_wc/wc-queries-test.c
>
> On
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: woensdag 23 mei 2012 4:56
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1341684 - in /subversion/trunk:
build/transform_sql.py
> subversion/libsvn_wc/wc-queries.sql subversion/tests/libsvn_wc/wc-querie
10 matches
Mail list logo