subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn commit: r1447487 - /subversion/trunk/subversion/svn/svn.c
Date Mon, 18 Feb 2013 21:21:16 GMT


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


Mime
View raw message