Stefan K√ľng <tortoisesvn_at_gmail.com> writes:
> * create a repository with the attached dump
> * check out a working copy from trunk, named "rcwc"
> $ svn merge -r7:4 rcwc\main.c
> works ok. But now the second merge:
> $ svn merge -r7:2 rcwc\main.c
> svn asks now what to do with the conflict. To get the working copy
> corrupted now, you have to return 'postpone' from the callback (do not
> return SVN_ERR_CANCELLED yet!), but on the next call to
> ctx->cancel_func return an SVN_ERR_CANCELLED.
I've managed to reproduce this using the command line client on Linux.
Set a breakpoint on libsvn_client/merge.c:1320 in conflict_resolver
where it records postpones. When that first breakpoint is reached set a
second breakpoint on svn_cl__check_cancel. When the second breakpoint
is the workqueue looks like:
5|(file-translate main.c svn-s9NVNg main.c.merge-left.r7)
6|(file-translate main.c svn-Wsq0E7 main.c.merge-right.r2)
7|(file-translate main.c 15 /tmp/svn-kILa4q main.c.working)
8|(tmp-set-text-conflict-markers main.c main.c.merge-left.r7 main.c.merge-right.r2 main.c.working)
9|(file-install main.c 1 0 1 0 19 .svn/tmp/main.c.tmp)
10|(file-remove 19 .svn/tmp/main.c.tmp)
The file /tmp/svn-kILa4q exists. Set cancelled=1 and continue the
program to exit via cancellation. The workqueue items still exist but
the file has been removed, so cleanup fails:
subversion/svn/svn cleanup wc
svn: E000002: Can't open file '/tmp/svn-kILa4q': No such file or directory
We seem to have three different sorts of temporary file names: some in
the working directory, some in /tmp and some in .svn/tmp. The files in
the working directory still exist, as does the file in .svn/tmp. I
assume a pool cleanup is removing the file from /tmp.
Why do we have three different sorts of temporary files? I can see that
if we have no working copy we need to use /tmp, but why do we put
temporary files in two different places inside the working copy? Why do
we use /tmp when we have a working copy?
Received on 2011-06-14 18:22:22 CEST