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
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 both with
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 Mac OS X
On 08/03/11 05:34, Justin Erenkrantz wrote:
On Mon, Mar 7, 2011 at 3:26 PM, John Beranek j...@redux.org.uk 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
On Tue, Mar 8, 2011 at 12:21, John Beranek j...@redux.org.uk wrote:
On 08/03/11 05:34, Justin Erenkrantz wrote:
On Mon, Mar 7, 2011 at 3:26 PM, John Beranek j...@redux.org.uk wrote:
Hmm...I'm surprised (and disappointed). No one is interested in
Subversion 1.7 being lower performance than 1.6?
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 and
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
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
stef...@apache.org writes:
Author: stefan2
Date: Mon Mar 7 22:57:04 2011
New Revision: 1079008
URL: http://svn.apache.org/viewvc?rev=1079008view=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 should
be
On 08/03/11 09:34, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 12:21, John Beranek j...@redux.org.uk wrote:
On 08/03/11 05:34, Justin Erenkrantz wrote:
On Mon, Mar 7, 2011 at 3:26 PM, John Beranek j...@redux.org.uk wrote:
Hmm...I'm surprised (and disappointed). No one is interested in
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=1079008view=rev
Log:
Set FSFS cache default size to 16 MB. This is the same default
On Tue, Mar 8, 2011 at 17:01, John Beranek j...@redux.org.uk wrote:
On 08/03/11 09:34, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 12:21, John Beranek j...@redux.org.uk wrote:
On 08/03/11 05:34, Justin Erenkrantz wrote:
On Mon, Mar 7, 2011 at 3:26 PM, John Beranek j...@redux.org.uk wrote:
On Tue, Mar 8, 2011 at 17:01, Stefan Sperling s...@elego.de 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=1079008view=rev
On Tue, Mar 8, 2011 at 9:07 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Tue, Mar 8, 2011 at 17:01, John Beranek j...@redux.org.uk wrote:
On 08/03/11 09:34, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 12:21, John Beranek j...@redux.org.uk wrote:
On 08/03/11 05:34, Justin Erenkrantz wrote:
On
On Tue, Mar 8, 2011 at 17:11, Mark Phippard markp...@gmail.com wrote:
On Tue, Mar 8, 2011 at 9:07 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Tue, Mar 8, 2011 at 17:01, John Beranek j...@redux.org.uk wrote:
On 08/03/11 09:34, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 12:21, John Beranek
Stefan Sperling s...@elego.de 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
-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:01,
On Tue, Mar 8, 2011 at 9:14 AM, Ivan Zhakov i...@visualsvn.com 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
On Tue, Mar 8, 2011 at 17:20, Mark Phippard markp...@gmail.com wrote:
On Tue, Mar 8, 2011 at 9:14 AM, Ivan Zhakov i...@visualsvn.com 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
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 interested
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 surprised (and
On Tue, Mar 8, 2011 at 2:46 AM, Simon Wilson sepwil...@gmail.com 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
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 significant _reduction_ in
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 is
On 08/03/11 14:07, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 17:01, John Beranek j...@redux.org.uk wrote:
On 08/03/11 09:34, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 12:21, John Beranek j...@redux.org.uk wrote:
On 08/03/11 05:34, Justin Erenkrantz wrote:
On Mon, Mar 7, 2011 at 3:26 PM, John
On Sat, Mar 5, 2011 at 13:16, Philip Martin philip.mar...@wandisco.com wrote:
Greg Stein gst...@gmail.com 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
On Sun, Mar 6, 2011 at 3:14 PM, Daniel Shahaf d...@daniel.shahaf.name 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=1076726view=rev
Log:
*
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
Greg Stein gst...@gmail.com 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
On Tue, Mar 08, 2011 at 02:15:06PM +, Philip Martin wrote:
Stefan Sperling s...@elego.de 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
Stefan Sperling s...@elego.de writes:
On Tue, Mar 08, 2011 at 02:15:06PM +, Philip Martin wrote:
Stefan Sperling s...@elego.de 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
Ivan Zhakov i...@visualsvn.com 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
user
On Tue, Mar 8, 2011 at 19:49, Philip Martin philip.mar...@wandisco.com wrote:
Ivan Zhakov i...@visualsvn.com 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
On 08/03/11 17:34, Ivan Zhakov wrote:
On Tue, Mar 8, 2011 at 19:49, Philip Martin philip.mar...@wandisco.com
wrote:
Ivan Zhakov i...@visualsvn.com 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
Ivan Zhakov i...@visualsvn.com writes:
On Tue, Mar 8, 2011 at 19:49, Philip Martin philip.mar...@wandisco.com
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,
On Mon, Mar 7, 2011 at 21:22, hwri...@apache.org 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
On Mon, Mar 7, 2011 at 20:33, hwri...@apache.org wrote:
Author: hwright
Date: Tue Mar 8 01:33:03 2011
New Revision: 1079070
URL: http://svn.apache.org/viewvc?rev=1079070view=rev
Log:
If we encounter an error while in an SQLite savepoint, back out the work
before returning. This mirrors
On Tue, Mar 8, 2011 at 12:52 PM, John Beranek j...@redux.org.uk 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
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:
On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov i...@visualsvn.com 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
On 08/03/2011 18:45, Mark Phippard wrote:
On Tue, Mar 8, 2011 at 12:52 PM, John Beranek j...@redux.org.uk 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
On Mon, Mar 7, 2011 at 16:03, hwri...@apache.org wrote:
Author: hwright
Date: Mon Mar 7 21:03:26 2011
New Revision: 1078949
URL: http://svn.apache.org/viewvc?rev=1078949view=rev
Log:
Move the call to determine_repos_info() inside the commit txn in libsvn_wc.
We want to ensure we are
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 executed in
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 more bogus is
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:
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=1078990r1=1078989r2=1078990view=diff
On Tue, Mar 8, 2011 at 14:35, John Beranek j...@redux.org.uk wrote:
On 08/03/2011 18:45, Mark Phippard wrote:
On Tue, Mar 8, 2011 at 12:52 PM, John Beranek j...@redux.org.uk wrote:
This reminds me that it's readily apparent that there is still no
pipelining being done on an import/commit in
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 11:08, Philip Martin philip.mar...@wandisco.com wrote:
Greg Stein gst...@gmail.com 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
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
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-REV *did*
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 packing the
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=1079008view=rev
Log:
Set FSFS cache default size to 16 MB. This is the same default as
for everybody else, namely the
On Tue, Mar 8, 2011 at 12:43 PM, Greg Stein gst...@gmail.com wrote:
On Mon, Mar 7, 2011 at 20:33, hwri...@apache.org wrote:
Author: hwright
Date: Tue Mar 8 01:33:03 2011
New Revision: 1079070
URL: http://svn.apache.org/viewvc?rev=1079070view=rev
Log:
If we encounter an error while in an
On 09/03/2011, at 2:03 AM, Hyrum K Wright wrote:
On Tue, Mar 8, 2011 at 2:46 AM, Simon Wilson sepwil...@gmail.com 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'
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
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=1079008view=rev
Log:
Set FSFS cache default size to
On Sat, Mar 5, 2011 at 8:27 AM, Daniel Becroft djcbecr...@gmail.com wrote:
On Fri, Mar 4, 2011 at 11:35 PM, Arwin Arni ar...@collab.net wrote:
On Friday 04 March 2011 05:15 PM, Philip Martin wrote:
Arwin Arniar...@collab.net writes:
On Friday 04 March 2011 04:52 PM, Philip Martin wrote:
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
while
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
On Tue, Mar 8, 2011 at 17:40, hwri...@apache.org wrote:
Author: hwright
Date: Tue Mar 8 22:40:09 2011
New Revision: 1079588
URL: http://svn.apache.org/viewvc?rev=1079588view=rev
Log:
Update the wc-ng stat caching code to use the well-established stringbuf,
rather than reinventing said
Julian Foad julian.f...@wandisco.com writes:
On Thu, 2011-03-03 at 22:48 +0530, Noorul Islam K M wrote:
Julian Foad julian.f...@wandisco.com writes:
On Wed, 2011-03-02, Noorul Islam K M wrote:
Please find attached patch for issue 3826. All tests pass using 'make
check'
[...]
Noorul Islam K M noo...@collab.net writes:
Stefan Sperling s...@elego.de 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;
-
63 matches
Mail list logo
