On Wed, Dec 1, 2021 at 7:31 PM Rolf Campbell <rolf.campb...@solace.com> wrote: > > 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?
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
