> -----Original Message-----
> From: rhuij...@apache.org [mailto:rhuij...@apache.org]
> Sent: maandag 18 februari 2013 21:51
> To: comm...@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@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
