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.