> -----Original Message-----
> From: rhuijben_at_apache.org [mailto:rhuijben_at_apache.org]
> Sent: maandag 18 februari 2013 21:51
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1447487 - /subversion/trunk/subversion/svn/svn.c
>
> Author: rhuijben
> Date: Mon Feb 18 20:51:15 2013
> New Revision: 1447487
>
> URL: http://svn.apache.org/r1447487
> Log:
> * subversion/svn/svn.c
> (sub_mail): Add comment noting backwards compatibility concern.
>
> Modified:
> subversion/trunk/subversion/svn/svn.c
>
> Modified: subversion/trunk/subversion/svn/svn.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/svn.c?rev=
> 1447487&r1=1447486&r2=1447487&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/svn/svn.c (original)
> +++ subversion/trunk/subversion/svn/svn.c Mon Feb 18 20:51:15 2013
> @@ -2530,6 +2530,17 @@ sub_main(int argc, const char *argv[], a
> SVN_CONFIG_SECTION_WORKING_COPY,
> SVN_CONFIG_OPTION_SQLITE_EXCLUSIVE,
> NULL);
> + /*
> ##########################################################
> ###############
> + This blocks every other application from accessing our wc.db at the same
> + time as this process. So instead of using the working copy lock functions
> + as designed other processes will already block before being able to check
> + that the working copy is locked and without a way to report what blocks
> + it or being able to recover using 'svn cleanup' when a process gets stuck
> +
> + BH: I call this a breaking change, but let's discuss that on dev_at_s.a.o.
> + first. This behavior should be opt-in, not opt-out until 2.0.
> +
> ##########################################################
> ###############
> + */
> if (!sqlite_exclusive)
> svn_config_set(cfg_config,
> SVN_CONFIG_SECTION_WORKING_COPY,
If I would use 1.8 to run
svn diff |more
And leave that open in a console I would block TortoiseSVN, AnkhSVN, Subclipse, etc on my entire working copy, while this command doesn't even obtain a working copy lock.
And as a developer on both 'svn' and AnkhSVN I often use 'svn diff' just for reviews.
And all those other clients would just hang without a way to recover... or fail with some sqlite error that they can't convert in something which they can translate to 'some stupid user exlusively locked the working copy by touching it with svn'
We designed working copy locks in our api to take care of the use cases where a client really needs to block out other clients on a part of the working copy, but we don't need them any more unless we revert this default change.
Maybe it gives a nice performance boost, but I don't think this should be the new default for 'svn'.
But this behavior change certainly explains why my recent performance profiles turned up pretty useless, while in the past they provided good inside in where we can improve the performance in real user performance in clients like AnkhSVN and TortoiseSVN.
Bert
Received on 2013-02-18 22:22:04 CET