Can't create temporary file from template ... No such file or directory

[Rolf Campbell]

I'm an svn administrator for my company and I end up doing a lot of merges.

Today, I ran into this failure (reproducable).

svn: warning: W000002: Can't create temporary file from template '/opt/sbox/rcampbell/auto-merge/solcbr/dataplane/sw/assuredDelivery/messageSpool/defrag/svn-XXXXXX': No such file or directory
svn: E155027: Failure occurred resolving one or more conflicts

This happens after I run two commands:

svn merge ^/trunk@184967 ^/trunk@185348 .  --accept postpone

and then

svn resolve solcbr/dataplane/sw/assuredDelivery/messageSpool

and then it gives me output:

$ svn resolve solcbr/dataplane/sw/assuredDelivery/messageSpool

Searching tree conflict details for 'solcbr/dataplane/sw/assuredDelivery/messageSpool' in repository:

Checking r184967... done

Tree conflict on 'solcbr/dataplane/sw/assuredDelivery/messageSpool':

A new directory appeared during merge of

'^/trunk/solcbr/dataplane/sw/assuredDelivery/messageSpool:184968-185348'.

It was added by solbuild in r184967.

A directory which already occupies this path was found in the working copy.

Select: (p) Postpone, (r) Mark as resolved, (i) Ignore incoming addition,

        (m) Merge the directories,

        (R) Delete my directory and replace it with incoming directory,

        (M) Replace and merge, (h) Help, (q) Quit resolution: m

C    solcbr/dataplane/sw/assuredDelivery/messageSpool/Rules.mk

svn: warning: W000002: Can't create temporary file from template '/opt/sbox/rcampbell/auto-merge/solcbr/dataplane/sw/assuredDelivery/messageSpool/defrag/svn-XXXXXX': No such file or directory

svn: E155027: Failure occurred resolving one or more conflicts

$ svn --version

svn, version 1.14.1 (r1886195)

   compiled Oct  1 2021, 11:42:52 on x86_64-unknown-linux-gnu

The directory "/opt/sbox/rcampbell/auto-merge/solcbr/dataplane/sw/assuredDelivery/messageSpool/defrag" does not exist because it is a subdirectory that was added in trunk but NOT added in the working branch.

We have already managed to get this merge to complete by renaming the directories so they don't collide, but this happens to us more than you might imagine and it would be nice if someone could take a look at this.  Am I doing something wrong or is this a bug in subversion?

-Rolf

---

Confidentiality notice

This e-mail message and any attachment hereto contain confidential information which may be privileged and which is intended for the exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or copying of this message and/or any attachment hereto without the consent of the sender is strictly prohibited. Thank you.

[Nathan Hartman]

Hi Rolf,

The first thing to find out is whether there is a bug in Subversion or
the cause is elsewhere.

The best way to track down the cause is with a reproduction script
that constructs a minimal repository that exposes the issue. Without
that, it is very difficult to know the cause. A reproduction script
would allow us to run the same steps on different machines with
different builds and versions of Subversion; if there is a bug, that
will help fix it and translated into a regression test to prevent it
from returning in the future.

For now, we can try to narrow it down:

When you say that this happens often, do you mean failure to create
temporary files? Has that started recently (e.g., with this install of
SVN 1.14.1)? Temporary file creation is done by APR. What version of
APR is used in this build? The output of 'svn --version --verbose'
gives the version of APR. What OS is used?

A potentially dumb question, but is it possible the volume where the
working copy is located is low of space?

If this happens again, could you try to run the same merge + resolve
(or whatever steps cause the issue to resurface) on a different
machine to see if the same failure occurs?

Thanks,
Nathan

[Rolf Campbell]

Hello Nathan,

Thank you for the reply.

I assure you that it was not related to disk space.  I tried it on 3 different computers using 2 different versions of SVN.

I tried to create a reproduction script and instead I caused the svn client to crash.

Here is my script:

svnadmin create test

svn checkout file://$PWD/test test.1

cd test.1

svn mkdir ^/trunk -m ""

svn mkdir ^/branches -m ""

touch a

svn add a

svn commit -m ""

svn cp ^/trunk ^/branches/b -m ""

svn mkdir ^/trunk/c -m ""

svn mkdir ^/trunk/c/d -m ""

svn mkdir ^/branches/b/c -m ""

svn mkdir ^/branches/b/c/e -m ""

cd ..

svn co file://$PWD/test/branches/b

cd b

svn merge ^/trunk .

And here is the output when I try it (multiple times):

--- Merging r4 through r8 into '.':

   C c

   A c/d

--- Recording mergeinfo for merge of r4 through r8 into '.':

 U   .

Summary of conflicts:

  Tree conflicts: 1

Searching tree conflict details for 'c' in repository:

Checking r5... done

Tree conflict on 'c':

A new directory appeared during merge of

'^/trunk/c:4-8'.

It was added by rcampbell in r5.

A directory which already occupies this path was found in the working copy.

Select: (p) Postpone, (r) Mark as resolved, (i) Ignore incoming addition,

        (m) Merge the directories,

        (R) Delete my directory and replace it with incoming directory,

        (M) Replace and merge, (h) Help, (q) Quit resolution: m

svn: E235000: In file 'subversion/libsvn_wc/adm_ops.c' line 384: assertion failed (!copyfrom_url || (svn_uri_is_canonical(copyfrom_url, scratch_pool) && SVN_IS_VALID_REVNUM(copyfrom_rev)))

Aborted (core dumped)

---

From: Nathan Hartman <hartman...@gmail.com>
Sent: December 2, 2021 10:36
To: Rolf Campbell <Rolf.C...@solace.com>
Cc: us...@subversion.apache.org <us...@subversion.apache.org>
Subject: Re: Can't create temporary file from template ... No such file or directory

 

Warning – this email originated outside of Solace. Please think before you click or open any links or attachments. If this email is suspicious, report it to i...@solace.com

---

[Nathan Hartman]

Thank you for this reproduction script. This is extremely helpful! I
can confirm this reproduces the above error for me exactly. I tested
with 1.10.6, 1.14.1, and an unreleased build of trunk. In all three,
the assertion failure occurs on the same line 384. I'll try to figure
out where the code is taking a wrong turn. In the meantime, if you do
succeed in reproducing the original issue, please do let us know!

Thanks,
Nathan

[Rolf Campbell]

Thank you for this reproduction script. This is extremely helpful! I

can confirm this reproduces the above error for me exactly. I tested
with 1.10.6, 1.14.1, and an unreleased build of trunk. In all three,
the assertion failure occurs on the same line 384. I'll try to figure
out where the code is taking a wrong turn. In the meantime, if you do
succeed in reproducing the original issue, please do let us know!

Thanks,

Nathan

​I've tried a few more times to make a small reproduction of my original issue, but I just keep hitting the same assert every time.  I'm hoping that once that assert is fixed, maybe I can get to my original issue.