Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Oct 31, 2012 at 17:36:09 +:
>> Prabhu Gnana Sundar wrote:
>> > + revstr = "";
>> > + svn_handle_error2(notify->err, stderr, FALSE /* non-fatal */,
>> > + apr_psprintf(scratch_pool, "svnadmin: %s", revstr));
>> > + r
Julian Foad wrote on Wed, Oct 31, 2012 at 17:36:09 +:
> Prabhu Gnana Sundar wrote:
> > + revstr = "";
> > + svn_handle_error2(notify->err, stderr, FALSE /* non-fatal */,
> > + apr_psprintf(scratch_pool, "svnadmin: %s",
> > revstr));
> > + return;
>
Prabhu Gnana Sundar wrote:
> Index: subversion/svnadmin/main.c
[...]
> @@ -729,6 +734,7 @@
> {
> svn_stream_t *feedback_stream = baton;
> apr_size_t len;
> + const char *revstr;
You can put the variables in a local-scope block within the switch case...
> switch (notify->actio
Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Oct 31, 2012 at 17:14:02 +:
>> Prabhu Gnana Sundar wrote:
>> > +notify_verification_error(svn_revnum_t rev, svn_error_t *err,
>> > + svn_repos_notify_func_t notify_func,
>> > + void *notify_
Julian Foad wrote on Wed, Oct 31, 2012 at 17:14:02 +:
> Prabhu Gnana Sundar wrote:
> > +notify_verification_error(svn_revnum_t rev, svn_error_t *err,
> > + svn_repos_notify_func_t notify_func,
> > + void *notify_baton, apr_pool_t *pool)
Anothe
Prabhu Gnana Sundar wrote:
> Index: subversion/libsvn_repos/dump.c
[...]
>
> +void
Doc string?
> +notify_verification_error(svn_revnum_t rev, svn_error_t *err,
> + svn_repos_notify_func_t notify_func,
> + void *notify_baton, apr_pool_t *pool)
Prabhu Gnana Sundar wrote:
> @@ -2517,8 +2524,29 @@
> * cancel_baton as argument to see if the caller wishes to cancel the
> * verification.
> *
> + * If @a keep_going is @c TRUE, the verify process notifies the error message
> + * and continues. If @a notify_func is @c NULL, the verificatio
Thanks Daniel,
Attaching the patch that would fix the suggestions given by you.
Thanks and regards
Prabhu
On 10/31/2012 08:28 PM, Daniel Shahaf wrote:
Index: subversion/libsvn_repos/dump.c
===
--- subversion/libsvn_repos/dump.
Philip Martin:
> stef...@apache.org writes:
>> + /* Sanitize (in case of data corruption)
>> + */
>> + if (new_ns->data->count > MAX_ATOMIC_COUNT)
>> + new_ns->data->count = MAX_ATOMIC_COUNT;
>
> I'm still seeing a crash:
>
> 467 if (new_ns->data->count > MAX
stef...@apache.org writes:
> Author: stefan2
> Date: Wed Oct 31 14:19:59 2012
> New Revision: 1404159
>
> URL: http://svn.apache.org/viewvc?rev=1404159&view=rev
> Log:
> "Harden" our named atomics against data file corruption. Even if
> the memory block contains completely random data, we shall
He did indeed move it the wrong way and fixed it in r1403983.
On Wed, Oct 31, 2012 at 2:33 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: danie...@apache.org [mailto:danie...@apache.org]
>> Sent: woensdag 31 oktober 2012 05:50
>> To: comm...@subversion.apache.org
>> Subject: s
> Index: subversion/libsvn_repos/dump.c
> ===
> --- subversion/libsvn_repos/dump.c(revision 1402414)
> +++ subversion/libsvn_repos/dump.c(working copy)
> @@ -1359,10 +1359,23 @@
>return close_directory(dir_baton, pool);
>
On Wed, Oct 31, 2012 at 2:54 PM, Philip Martin
wrote:
> Philip Martin writes:
>
> > Stefan Fuhrmann writes:
> >
> >> Excellent analysis, Philip! With r1404112, we use "plain"
> >> APR mmap code with almost no coding overhead.
> >> The only downside is that we now have a temporary
> >> file sitti
Philip Martin writes:
> Stefan Fuhrmann writes:
>
>> Excellent analysis, Philip! With r1404112, we use "plain"
>> APR mmap code with almost no coding overhead.
>> The only downside is that we now have a temporary
>> file sitting in the db folder.
>
> Error handling needs attention:
>
> $ svnadmi
On Wed, Oct 31, 2012 at 2:15 PM, Philip Martin
wrote:
> Philip Martin writes:
>
> > stef...@apache.org writes:
> >
> >> Author: stefan2
> >> Date: Wed Oct 31 12:27:29 2012
> >> New Revision: 1404112
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1404112&view=rev
> >> Log:
> >> Change the way we
On Wed, Oct 31, 2012 at 1:53 PM, Bert Huijben wrote:
>
> > -Original Message-
> > From: stef...@apache.org [mailto:stef...@apache.org]
> > Sent: maandag 29 oktober 2012 15:28
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1403312 -
> > /subversion/trunk/subversion/libsvn_
Philip Martin writes:
> stef...@apache.org writes:
>
>> Author: stefan2
>> Date: Wed Oct 31 12:27:29 2012
>> New Revision: 1404112
>>
>> URL: http://svn.apache.org/viewvc?rev=1404112&view=rev
>> Log:
>> Change the way we implement shared memory setup for our named atomics.
>> Instead of using APR
stef...@apache.org writes:
> Author: stefan2
> Date: Wed Oct 31 12:27:29 2012
> New Revision: 1404112
>
> URL: http://svn.apache.org/viewvc?rev=1404112&view=rev
> Log:
> Change the way we implement shared memory setup for our named atomics.
> Instead of using APR's SHM API, we create a persistent
> -Original Message-
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: maandag 29 oktober 2012 15:28
> To: comm...@subversion.apache.org
> Subject: svn commit: r1403312 -
> /subversion/trunk/subversion/libsvn_ra/ra_loader.c
>
> Author: stefan2
> Date: Mon Oct 29 14:28:17 201
Stefan Fuhrmann writes:
> Excellent analysis, Philip! With r1404112, we use "plain"
> APR mmap code with almost no coding overhead.
> The only downside is that we now have a temporary
> file sitting in the db folder.
Error handling needs attention:
$ svnadmin create repo
$ svnadmin dump repo >
> -Original Message-
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: woensdag 31 oktober 2012 13:27
> To: comm...@subversion.apache.org
> Subject: svn commit: r1404112 - in /subversion/trunk/subversion:
> include/private/svn_named_atomic.h libsvn_fs_fs/fs_fs.c
> libsvn_subr
On Tue, Oct 30, 2012 at 7:18 PM, Stefan Sperling wrote:
> On Tue, Oct 30, 2012 at 05:58:20PM +, Philip Martin wrote:
> > Another approach would be to create the shared memory created from some
> > other, long-lived, process. The user would have to run this process to
> > enable caching. To
On Tue, Oct 30, 2012 at 6:58 PM, Philip Martin
wrote:
> Philip Martin writes:
>
> > That's a serious problem, the two processes are not longer using the
> > same shared memory segment to keep in sync. Changes made by one process
> > won't be visible to another.
>
> I don't see how to fix this wi
Thanks Stefan,
Addressed the suggestions in this patch. Attaching the log message too
with this mail.
Please share your thoughts...
Thanks and regards
Prabhu
On 10/30/2012 08:38 PM, Stefan Sperling wrote:
On Tue, Oct 30, 2012 at 04:07:49PM +0200, Daniel Shahaf wrote:
Prabhu Gnana Sundar w
1.7.0@1181106 vs. trunk@1404079
Started at Wed Oct 31 10:38:50 UTC 2012
*DISCLAIMER* - This tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.
Charts of t
Johan Corveleyn writes:
> If this is hard to handle in practice, and a long running
> multi-threaded client has to wait anyway for an entire write operation
> to be finished, I'm wondering if it would be much easier for such
> clients to also always use the "exclusive locking" mode. It would make
On Fri, Oct 26, 2012 at 4:10 PM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> - This 10 second timeout, for a read operation that is blocked by some
>> write transaction: is this implemented somewhere in the svn source
>> code (if so, where?), or is this some configuration setting for the
> -Original Message-
> From: danie...@apache.org [mailto:danie...@apache.org]
> Sent: woensdag 31 oktober 2012 05:50
> To: comm...@subversion.apache.org
> Subject: svn commit: r1403979 -
> /subversion/trunk/subversion/libsvn_subr/io.c
>
> Author: danielsh
> Date: Wed Oct 31 04:50:22 2012
On Tue, Oct 30, 2012 at 9:28 PM, Daniel Shahaf wrote:
> i...@apache.org wrote on Tue, Oct 30, 2012 at 15:09:57 -:
>> Author: ivan
>> Date: Tue Oct 30 15:09:56 2012
>> New Revision: 1403733
>>
>> URL: http://svn.apache.org/viewvc?rev=1403733&view=rev
>> Log:
>> * subversion/libsvn_ra_serf/serf.
29 matches
Mail list logo
