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.
Bug
Major