Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4412

report_context_t.lock_token_paths don't match

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: ---
    • Component/s: libsvn_ra_serf
    • Labels:
      None

      Description

      There is a path handling bug in libsvn_ra_serf/update.c for
      report_context_t.lock_path_tokens.
      
      svnadmin create repo --compatible-version 1.6
      svn -mm import repo/format file://`pwd`/repo/A/f
      svn co http://localhost:8888/obj/repo wc
      svn lock wc/A/f
      svn up wc/A
      svn up wc
      
      With a pre-1.6.17 server the update of 'wc/A' is a no-op but the update of 'wc'
      breaks the lock.  This problem goes away in 1.6.17 due to r1124173 but the path
      handling bug remains.
      
      A 1.6.16 server sends an update report that opens and closes A/f and
      libsvn_ra_serf/update.c:check_lock breaks the lock.  The reason that the subdir
      update doesn't break the lock is that the path handling for lock_path_tokens is
      broken:
      
      Breakpoint 4, set_path (report_baton=0x7ffff7f9a698, path=0x7ffff7f480a0 "f", 
          revision=1, depth=svn_depth_infinity, start_empty=0, 
          lock_token=0x7ffff7f9c110
      "opaquelocktoken:a8e663d6-1a76-4cd5-a276-c05ed1987f63", pool=0x7ffff7f48028) at
      ../src/subversion/libsvn_ra_serf/update.c:2646
      2646	      svn_hash_sets(report->lock_path_tokens,
      (gdb) p path
      $10 = 0x7ffff7f480a0 "f"
      (gdb) c
      Continuing.
      
      Breakpoint 3, end_report (parser=0x7ffff7f9c5e8, name=..., 
          scratch_pool=0x7ffff7f20028)
          at ../src/subversion/libsvn_ra_serf/update.c:2247
      2247	      info->lock_token = svn_hash_gets(ctx->lock_path_tokens, info->name);
      (gdb) p info->name
      $11 = 0x7ffff7f1c938 "A/f"
      (gdb) 
      
      We populate the hash with path "f" and query the hash with path "A/f". When the
      query returns NULL the lock is not broken.  When the update target is the root
      of the working copy the hash is populated with "A/f", the query returns the lock
      and then the lock is broken.
      

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              philipm Philip Martin
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: