[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1104309 - in /subversion/trunk/subversion: libsvn_repos/reporter.c tests/cmdline/lock_tests.py tests/cmdline/update_tests.py

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 17 May 2011 18:34:28 +0200

On Tue, May 17, 2011 at 5:02 PM, <cmpilato_at_apache.org> wrote:
> Author: cmpilato
> Date: Tue May 17 15:02:05 2011
> New Revision: 1104309
>
> URL: http://svn.apache.org/viewvc?rev=1104309&view=rev
> Log:
> With rhuijben, avoid transmitting entry props for unmodified, locked
> files when the client-provided lock token matches what is stored in
> the repository.  This fixes issue #3525 ("Locked file which is
> scheduled for delete causes tree conflict") and issue #3471 ("svn up
> touches file w/ lock & svn:keywords property").
>
> NOTE:  There is a remaining 3525-related test that is still failing
> (update_tests.py 53), but that's because of out-of-date expectations
> in the WC-NG world.  (That will be fixed in a subsequent revision.)
>
> * subversion/libsvn_repos/reporter.c
>  (update_entry): Return early not only when there's not a provided
>    lock token, but also when there's a provided lock token that matches
>    what's in the repository.
>
> * subversion/tests/cmdline/lock_tests.py
>  (update_locked_deleted): Remove @XFail decorator.
>
> * subversion/tests/cmdline/update_tests.py
>  (update_with_file_lock_and_keywords_property_set): Remove @XFail decorator.
>
> Modified:
>    subversion/trunk/subversion/libsvn_repos/reporter.c
>    subversion/trunk/subversion/tests/cmdline/lock_tests.py
>    subversion/trunk/subversion/tests/cmdline/update_tests.py
>
> Modified: subversion/trunk/subversion/libsvn_repos/reporter.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_repos/reporter.c?rev=1104309&r1=1104308&r2=1104309&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_repos/reporter.c (original)
> +++ subversion/trunk/subversion/libsvn_repos/reporter.c Tue May 17 15:02:05 2011
> @@ -860,9 +860,23 @@ update_entry(report_baton_t *b, svn_revn
>     {
>       int distance = svn_fs_compare_ids(s_entry->id, t_entry->id);
>       if (distance == 0 && !any_path_info(b, e_path)
> -          && (!info || (!info->start_empty && !info->lock_token))
>           && (requested_depth <= wc_depth || t_entry->kind == svn_node_file))
> -        return SVN_NO_ERROR;
> +        {
> +          if (!info)
> +            return SVN_NO_ERROR;
> +
> +          if (!info->start_empty)
> +            {
> +              svn_lock_t *lock;
> +
> +              if (!info->lock_token)
> +                return SVN_NO_ERROR;
> +
> +              SVN_ERR(svn_fs_get_lock(&lock, b->repos->fs, t_path, pool));

Could t_path be NULL here (if only if a "malicious client" crafts a
special request)?

The docstring of this function mentions that T_ENTRY and T_PATH may be
NULL. In this block we are sure that T_ENTRY is non-null, but what
about T_PATH?

-- 
Johan
Received on 2011-05-17 18:35:16 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.