Noorul Islam K M writes:
> Stefan Sperling writes:
>
>> On Thu, Mar 03, 2011 at 10:39:11PM +0530, Noorul Islam K M wrote:
>>
>>> @@ -164,9 +171,18 @@
>>>if (tmpinfo->depth == svn_depth_unknown)
>>> tmpinfo->depth = svn_depth_infinity;
>>>
>>> - SVN_ERR(svn_wc__node_get_schedule(&tmpi
Julian Foad writes:
> On Thu, 2011-03-03 at 22:48 +0530, Noorul Islam K M wrote:
>
>> Julian Foad writes:
>>
>> > On Wed, 2011-03-02, Noorul Islam K M wrote:
>> >
>> >> Please find attached patch for issue 3826. All tests pass using 'make
>> >> check'
>> > [...]
>> >> Index: subversion/svn/dif
On Tue, Mar 8, 2011 at 17:40, wrote:
> Author: hwright
> Date: Tue Mar 8 22:40:09 2011
> New Revision: 1079588
>
> URL: http://svn.apache.org/viewvc?rev=1079588&view=rev
> Log:
> Update the wc-ng stat caching code to use the well-established stringbuf,
> rather than reinventing said wheel.
Cool
1. For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y
doesn't exist. Instead, automatically substitute for Y the last revision in
which PATH@THAT-REV *did* exist, and continue the operation. I believe this
is something that we can reasonably achieve without too much trouble an
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 22:12:59 +0100:
> On 08.03.2011 21:24, Daniel Shahaf wrote:
> >Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
> >>On 08.03.2011 20:58, Daniel Shahaf wrote:
> >>>Looks like r1078357 is the culprit: r1078340 loads the dump successfully
> >>
On Sat, Mar 5, 2011 at 8:27 AM, Daniel Becroft wrote:
> On Fri, Mar 4, 2011 at 11:35 PM, Arwin Arni wrote:
>
>> On Friday 04 March 2011 05:15 PM, Philip Martin wrote:
>>
>>> Arwin Arni writes:
>>>
>>> On Friday 04 March 2011 04:52 PM, Philip Martin wrote:
> Arwin Arni writes:
>
On 08.03.2011 15:01, Stefan Sperling wrote:
On Tue, Mar 08, 2011 at 01:46:23PM +, Philip Martin wrote:
stef...@apache.org writes:
Author: stefan2
Date: Mon Mar 7 22:57:04 2011
New Revision: 1079008
URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
Log:
Set FSFS cache default size to
On 08.03.2011 21:24, Daniel Shahaf wrote:
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
On 08.03.2011 20:58, Daniel Shahaf wrote:
Looks like r1078357 is the culprit: r1078340 loads the dump successfully
while r1078365 croaks.
r1078357 is the merging of the integrate-txdelta-cac
On 09/03/2011, at 2:03 AM, Hyrum K Wright wrote:
> On Tue, Mar 8, 2011 at 2:46 AM, Simon Wilson wrote:
>>
On Mon, Mar 07, 2011 at 08:59:35AM +0100, Simon Wilson wrote:
> I'm posting here for feedback before opening an issue with Subversion
> tracker.
>
> Using the 'svn mkd
On Tue, Mar 8, 2011 at 12:43 PM, Greg Stein wrote:
> On Mon, Mar 7, 2011 at 20:33, wrote:
>> Author: hwright
>> Date: Tue Mar 8 01:33:03 2011
>> New Revision: 1079070
>>
>> URL: http://svn.apache.org/viewvc?rev=1079070&view=rev
>> Log:
>> If we encounter an error while in an SQLite savepoint, b
On 08.03.2011 14:46, Philip Martin wrote:
stef...@apache.org writes:
Author: stefan2
Date: Mon Mar 7 22:57:04 2011
New Revision: 1079008
URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
Log:
Set FSFS cache default size to 16 MB. This is the same default as
for everybody else, namely the
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 21:06:03 +0100:
> On 08.03.2011 20:58, Daniel Shahaf wrote:
> >Looks like r1078357 is the culprit: r1078340 loads the dump successfully
> >while r1078365 croaks.
> >
> >r1078357 is the merging of the integrate-txdelta-caching branch.
>
> Are you packin
On Tue, Mar 08, 2011 at 05:05:10PM +0100, Avalon wrote:
> >There are now two different issues brought up in these thread:
> >
> >1. For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y
> >doesn't exist. Instead, automatically substitute for Y the last revision in
> >which PATH@THAT
On 08.03.2011 20:58, Daniel Shahaf wrote:
Looks like r1078357 is the culprit: r1078340 loads the dump successfully
while r1078365 croaks.
r1078357 is the merging of the integrate-txdelta-caching branch.
Are you packing the repository while loading it?
What environment are you using (since I fa
On Tue, Mar 8, 2011 at 11:08, Philip Martin wrote:
> Greg Stein writes:
>
>> And to be clear: the server *could* just remain silent, and the proxy
>> would insert the SVN-VTxn-Name header in the response back to the
>> client, right? Would that be an improvement/simplification?
>
> I don't think
Looks like r1078357 is the culprit: r1078340 loads the dump successfully
while r1078365 croaks.
r1078357 is the merging of the integrate-txdelta-caching branch.
On Tue, Mar 8, 2011 at 14:35, John Beranek wrote:
> On 08/03/2011 18:45, Mark Phippard wrote:
>> On Tue, Mar 8, 2011 at 12:52 PM, John Beranek wrote:
>>
>>> This reminds me that it's readily apparent that there is still no
>>> pipelining being done on an import/commit in either ra_neon or ra_serf
On 07.03.2011 23:40, Daniel Shahaf wrote:
stef...@apache.org wrote on Mon, Mar 07, 2011 at 22:28:25 -:
Modified: subversion/trunk/subversion/libsvn_fs_fs/caching.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/caching.c?rev=1078990&r1=1078989&r2=1078990&view=dif
On 07.03.2011 13:11, Philip Martin wrote:
stef...@apache.org writes:
Author: stefan2
Date: Sat Mar 5 21:18:33 2011
New Revision: 1078357
Modified: subversion/trunk/subversion/svnadmin/main.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svnadmin/main.c?rev=1078357&r1=1078356&r2
Daniel Shahaf wrote on Tue, Mar 08, 2011 at 21:34:48 +0200:
> Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 20:01:56 +0100:
> > On 07.03.2011 21:47, Daniel Shahaf wrote:
> > >svn-bisect says this started in r1078366.
> > >
> > Hm. I'm unable to reproduce the issue here (64 bit linux).
> > What's mo
Stefan Fuhrmann wrote on Tue, Mar 08, 2011 at 20:01:56 +0100:
> On 07.03.2011 21:47, Daniel Shahaf wrote:
> >svn-bisect says this started in r1078366.
> >
> Hm. I'm unable to reproduce the issue here (64 bit linux).
> What's more bogus is that the code changed in 1078366
> should not even get execu
On Mon, Mar 7, 2011 at 16:03, wrote:
> Author: hwright
> Date: Mon Mar 7 21:03:26 2011
> New Revision: 1078949
>
> URL: http://svn.apache.org/viewvc?rev=1078949&view=rev
> Log:
> Move the call to determine_repos_info() inside the commit txn in libsvn_wc.
> We want to ensure we are acting on vali
On 08/03/2011 18:45, Mark Phippard wrote:
> On Tue, Mar 8, 2011 at 12:52 PM, John Beranek wrote:
>
>> This reminds me that it's readily apparent that there is still no
>> pipelining being done on an import/commit in either ra_neon or ra_serf,
>> even with a 'v2' server. Here's some numbers for th
On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov wrote:
>...
> It seems I found reason why ra_serf is slower than ra_neon. ra_serf
> sends CHECKOUT request for _each_ folder and file that being imported,
> while ra_neon perform it only for root directory. Maybe DAV experts
> can answer which behavior is
On 07.03.2011 21:47, Daniel Shahaf wrote:
svn-bisect says this started in r1078366.
Hm. I'm unable to reproduce the issue here (64 bit linux).
What's more bogus is that the code changed in 1078366
should not even get executed in your scenario.
Can you try the following patch:
Index: subversio
On Tue, Mar 8, 2011 at 12:52 PM, John Beranek wrote:
> This reminds me that it's readily apparent that there is still no
> pipelining being done on an import/commit in either ra_neon or ra_serf,
> even with a 'v2' server. Here's some numbers for that, again the same
> dataset I've been using, now
On Mon, Mar 7, 2011 at 20:33, wrote:
> Author: hwright
> Date: Tue Mar 8 01:33:03 2011
> New Revision: 1079070
>
> URL: http://svn.apache.org/viewvc?rev=1079070&view=rev
> Log:
> If we encounter an error while in an SQLite savepoint, back out the work
> before returning. This mirrors the behavi
On Mon, Mar 7, 2011 at 21:22, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/wc_db_private.h Tue Mar 8 02:22:16
> 2011
> @@ -52,6 +52,15 @@ struct svn_wc__db_t {
> const char *local_abspath -> svn_wc__db_wcroot_t *wcroot */
> apr_hash_t *dir_data;
>
> + /* A few members to ass
Ivan Zhakov writes:
> On Tue, Mar 8, 2011 at 19:49, Philip Martin
> wrote:
>> Importing a Subversion wc, client on laptop, server on desktop, across
>> LAN:
>>
>> 1.6.x client, 1.6.x server, serf : 20s
>> trunk client, 1.6.x server, serf : 34s
>> 1.6.x client, trunk server, serf : 20s
>> trunk
On 08/03/11 17:34, Ivan Zhakov wrote:
> On Tue, Mar 8, 2011 at 19:49, Philip Martin
> wrote:
>> Ivan Zhakov writes:
>>
>>> So, as a comparison, I ran the same tests to a localhost trunk(r1078338)
>>> server. Fedora 14 x86_64, Apache 2.2.17.
>>>
>>> trunk (http-library=neon):
>>> real0m20.785
On Tue, Mar 8, 2011 at 19:49, Philip Martin wrote:
> Ivan Zhakov writes:
>
>> So, as a comparison, I ran the same tests to a localhost trunk(r1078338)
>> server. Fedora 14 x86_64, Apache 2.2.17.
>>
>> trunk (http-library=neon):
>> real 0m20.785s
>> user 0m0.912s
>> sys 0m1.659s
>>
>> tr
Ivan Zhakov writes:
> So, as a comparison, I ran the same tests to a localhost trunk(r1078338)
> server. Fedora 14 x86_64, Apache 2.2.17.
>
> trunk (http-library=neon):
> real0m20.785s
> user0m0.912s
> sys 0m1.659s
>
> trunk (http-library=serf):
> real0m21.351s
> user0m0.873s
Stefan Sperling writes:
> On Tue, Mar 08, 2011 at 02:15:06PM +, Philip Martin wrote:
>> Stefan Sperling writes:
>>
>> > So I think it would be better if the cache was off by default, and must be
>> > enabled in a configuration file. I suppose svnserve and mod_dav_svn
>> > configuration file
On Tue, Mar 08, 2011 at 02:15:06PM +, Philip Martin wrote:
> Stefan Sperling writes:
>
> > So I think it would be better if the cache was off by default, and must be
> > enabled in a configuration file. I suppose svnserve and mod_dav_svn
> > configuration files would be the best location for
Greg Stein writes:
> And to be clear: the server *could* just remain silent, and the proxy
> would insert the SVN-VTxn-Name header in the response back to the
> client, right? Would that be an improvement/simplification?
I don't think so.
Normal operation:
- client sends POST
- server crea
There are now two different issues brought up in these thread:
1. For 'svn log -rX:Y PATH@PEG, where Y> PEG, don't croak when PATH@Y
doesn't exist. Instead, automatically substitute for Y the last revision in
which PATH@THAT-REV *did* exist, and continue the operation. I believe this
is somet
On Sun, Mar 6, 2011 at 3:14 PM, Daniel Shahaf wrote:
> pbu...@apache.org wrote on Thu, Mar 03, 2011 at 19:09:01 -:
>> Author: pburba
>> Date: Thu Mar 3 19:09:01 2011
>> New Revision: 1076726
>>
>> URL: http://svn.apache.org/viewvc?rev=1076726&view=rev
>> Log:
>> * subversion/tests/cmdline/log
On Sat, Mar 5, 2011 at 13:16, Philip Martin wrote:
> Greg Stein writes:
>
>>> If the client sends, or a proxy injects, an SVN-VTxn-Name header with
>>> the POST request it defines the transaction name to be returned to the
>>> client in the POST response. If the client recieves the new
>>> SVN-V
On 08/03/11 14:07, Ivan Zhakov wrote:
> On Tue, Mar 8, 2011 at 17:01, John Beranek wrote:
>> On 08/03/11 09:34, Ivan Zhakov wrote:
>>> On Tue, Mar 8, 2011 at 12:21, John Beranek wrote:
On 08/03/11 05:34, Justin Erenkrantz wrote:
> On Mon, Mar 7, 2011 at 3:26 PM, John Beranek wrote:
On 03/08/2011 05:11 AM, Avalon wrote:
> I would appreciate the feature since it would also be very useful for tools
> like WebSVN.
> How realistic would it be to get it implemented in the near future?
> While having good programming skill i have never compiled subversion myself.
> But if any help i
On Tue, 2011-03-08, John Beranek wrote:
> On 08/03/11 12:31, Julian Foad wrote:
> > On Mon, 2011-03-07, John Beranek wrote:
> >> On 05/03/2011 23:23, John Beranek wrote:
> >>> Hi,
> >>>
> >>> I'm not sure if much performance comparison has been performed, but I'm
> >>> unhappy to report a significa
On Tue, Mar 8, 2011 at 2:46 AM, Simon Wilson wrote:
>
>>> On Mon, Mar 07, 2011 at 08:59:35AM +0100, Simon Wilson wrote:
I'm posting here for feedback before opening an issue with Subversion
tracker.
Using the 'svn mkdir' command against a 1.5/1.6 format repository via
ra
On 08/03/11 12:31, Julian Foad wrote:
> On Mon, 2011-03-07, John Beranek wrote:
>> On 05/03/2011 23:23, John Beranek wrote:
>>> Hi,
>>>
>>> I'm not sure if much performance comparison has been performed, but I'm
>>> unhappy to report a significant _reduction_ in speed in a checkout.
>>
>> Hmm...I'm
On Mon, 2011-03-07, John Beranek wrote:
> On 05/03/2011 23:23, John Beranek wrote:
> > Hi,
> >
> > I'm not sure if much performance comparison has been performed, but I'm
> > unhappy to report a significant _reduction_ in speed in a checkout.
>
> Hmm...I'm surprised (and disappointed). No one is
On Tue, Mar 8, 2011 at 17:20, Mark Phippard wrote:
> On Tue, Mar 8, 2011 at 9:14 AM, Ivan Zhakov wrote:
[1] http://serf.googlecode.com/svn/trunk/
>>>
>>> Don't the tests show that trunk is slightly faster than 1.6? It seems
>>> like the main thing it shows is that when working with a HTTPv1
On Tue, Mar 8, 2011 at 9:14 AM, Ivan Zhakov wrote:
>>> [1] http://serf.googlecode.com/svn/trunk/
>>
>> Don't the tests show that trunk is slightly faster than 1.6? It seems
>> like the main thing it shows is that when working with a HTTPv1
>> server, ra_serf is significantly slower than ra_neon f
> -Original Message-
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: dinsdag 8 maart 2011 15:08
> To: Philip Martin; dev@subversion.apache.org
> Cc: Stefan Sperling
> Subject: Re: svn commit: r1079008 -
> /subversion/trunk/subversion/svnadmin/main.c
>
> On Tue, Mar 8, 2011 at 17:
Stefan Sperling writes:
> So I think it would be better if the cache was off by default, and must be
> enabled in a configuration file. I suppose svnserve and mod_dav_svn
> configuration files would be the best location for this,
svnserve doesn't have a configuration file. There is a per-reposi
On Tue, Mar 8, 2011 at 17:11, Mark Phippard wrote:
> On Tue, Mar 8, 2011 at 9:07 AM, Ivan Zhakov wrote:
>> On Tue, Mar 8, 2011 at 17:01, John Beranek wrote:
>>> On 08/03/11 09:34, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 12:21, John Beranek wrote:
> On 08/03/11 05:34, Justin Erenkrant
On Tue, Mar 8, 2011 at 9:07 AM, Ivan Zhakov wrote:
> On Tue, Mar 8, 2011 at 17:01, John Beranek wrote:
>> On 08/03/11 09:34, Ivan Zhakov wrote:
>>> On Tue, Mar 8, 2011 at 12:21, John Beranek wrote:
On 08/03/11 05:34, Justin Erenkrantz wrote:
> On Mon, Mar 7, 2011 at 3:26 PM, John Berane
On Tue, Mar 8, 2011 at 17:01, Stefan Sperling wrote:
> On Tue, Mar 08, 2011 at 01:46:23PM +, Philip Martin wrote:
>> stef...@apache.org writes:
>>
>> > Author: stefan2
>> > Date: Mon Mar 7 22:57:04 2011
>> > New Revision: 1079008
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1079008&view=re
On Tue, Mar 8, 2011 at 17:01, John Beranek wrote:
> On 08/03/11 09:34, Ivan Zhakov wrote:
>> On Tue, Mar 8, 2011 at 12:21, John Beranek wrote:
>>> On 08/03/11 05:34, Justin Erenkrantz wrote:
On Mon, Mar 7, 2011 at 3:26 PM, John Beranek wrote:
> Hmm...I'm surprised (and disappointed). No
On Tue, Mar 08, 2011 at 01:46:23PM +, Philip Martin wrote:
> stef...@apache.org writes:
>
> > Author: stefan2
> > Date: Mon Mar 7 22:57:04 2011
> > New Revision: 1079008
> >
> > URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
> > Log:
> > Set FSFS cache default size to 16 MB. This is t
On 08/03/11 09:34, Ivan Zhakov wrote:
> On Tue, Mar 8, 2011 at 12:21, John Beranek wrote:
>> On 08/03/11 05:34, Justin Erenkrantz wrote:
>>> On Mon, Mar 7, 2011 at 3:26 PM, John Beranek wrote:
Hmm...I'm surprised (and disappointed). No one is interested in
Subversion 1.7 being lower per
stef...@apache.org writes:
> Author: stefan2
> Date: Mon Mar 7 22:57:04 2011
> New Revision: 1079008
>
> URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
> Log:
> Set FSFS cache default size to 16 MB. This is the same default as
> for everybody else, namely the server processes. Thus, it sh
On Tue, Mar 08, 2011 at 09:21:58AM +, John Beranek wrote:
> I guess from now on I'll just keep my investigations to myself.
Please don't keep them to yourself. Any information you have might help.
Just keep in mind that we're already looking at this in detail.
E.g. detailed profiler output to
I believe that users expect
svn log -rREV1:REV2 path@PEG
to mean "report everything that happened to path@REV between
revision REV1 and REV2, inclusive", with both creation and deletion
being events for potential inclusion in the report. It's unfriendly
for "path@PEG does not exist in revis
On Tue, Mar 08, 2011 at 09:38:02AM +0200, Alan Barrett wrote:
> On Mon, 07 Mar 2011, Stefan Sperling wrote:
> I believe that users expect
>
>svn log -rREV1:REV2 path@PEG
>
> to mean "report everything that happened to path@REV between
> revision REV1 and REV2, inclusive", with both creation a
On Tue, Mar 8, 2011 at 12:21, John Beranek wrote:
> On 08/03/11 05:34, Justin Erenkrantz wrote:
>> On Mon, Mar 7, 2011 at 3:26 PM, John Beranek wrote:
>>> Hmm...I'm surprised (and disappointed). No one is interested in
>>> Subversion 1.7 being lower performance than 1.6?
>>
>> You're not telling
On 08/03/11 05:34, Justin Erenkrantz wrote:
> On Mon, Mar 7, 2011 at 3:26 PM, John Beranek wrote:
>> Hmm...I'm surprised (and disappointed). No one is interested in
>> Subversion 1.7 being lower performance than 1.6?
>
> You're not telling us something we don't already know (go read the
> archive
>> On Mon, Mar 07, 2011 at 08:59:35AM +0100, Simon Wilson wrote:
>>> I'm posting here for feedback before opening an issue with Subversion
>>> tracker.
>>>
>>> Using the 'svn mkdir' command against a 1.5/1.6 format repository via
>>> ra_local (i.e. with a file:// URL) with 64-bit Subversion on
>> I'm posting here for feedback before opening an issue with Subversion
>> tracker.
>>
>> Using the 'svn mkdir' command against a 1.5/1.6 format repository via
>> ra_local (i.e. with a file:// URL) with 64-bit Subversion on Mac OS X
>> results in a segmentation fault. This 100% reproducible b
On Mon, 07 Mar 2011, Stefan Sperling wrote:
By asking for beta@4 with a revision range of 1:HEAD, we're
asking an invalid question because the revision range is not
valid for this path. There is no log to show in HEAD, so it
errors out (you can think of this as the filter trying to
eliminate
63 matches
Mail list logo
