Hi again,
I'm attaching a script that reproduces the behavior of checking revisions
before the branch was created as well as going back to the revision before the
file was created on trunk.
If you run the attached script and redirect the output to file, you'll see this:
--- Merging r3 through r5 into '.':
C testfile
--- Recording mergeinfo for merge of r3 through r5 into '.':
U .
Summary of conflicts:
Tree conflicts: 1
Searching tree conflict details for 'testfile' in repository:
Checking r2...Checking r4...Checking r5...Checking r3...Checking r2...Checking
r1...Checking r5... done
So despite the merge being for 3:5, it checks r2 (twice) and r1 once. As Stefan
stated, this may be completely reasonable due to the data structures, but for
our large and slow repo, this made merges impossible.
If there had been svn:mergeinfo on the branch, shouldn't it had been able to
stop at r3 in that case? I tried this on the full repo and still seemed to have
it go back further than expected.
Let me know if this is expected behavior or not and if there's anything else I
can help with analyzing it. Unfortunately, I can't give access to the
company-internal repo to test the actual problem.
TIA,
Chris
--------------------------------------------
On Wed, 4/25/18, Chris <devnullacco...@yahoo.se> wrote:
Subject: Re: Surprising behavior with 1.10 tree conflict resolver
To: "Chris" <devnullacco...@yahoo.se>, "Stefan Sperling" <s...@apache.org>
Cc: users@subversion.apache.org
Date: Wednesday, April 25, 2018, 2:03 PM
Hi Stefan and thanks for the reply.
(sorry about the top-posting, yahoo's
webmail isn't made for proper mail usage)
Good idea to try the non-interactive
and then resolve after, that seems to get me out of the bind
I got into, but I'll probably tell our users to stick to 1.9
for the time being.
I'm not sure I'll be able to recreate a
test for the strange behavior since it may have to do with
this being a very large and very old repo that I'm working
on. But I'll give it a try as soon as I have some time to
spare and post the result here (or the failure to repeat it
in a simple script).
/Chris
--------------------------------------------
On Wed, 4/25/18, Stefan Sperling <s...@apache.org>
wrote:
Subject: Re: Surprising behavior with
1.10 tree conflict resolver
To: "Chris" <devnullacco...@yahoo.se>
Cc: users@subversion.apache.org
Date: Wednesday, April 25, 2018, 1:37
PM
On Wed, Apr 25, 2018 at 11:04:13AM
+0000, Chris
wrote:
> I'm trying out subversion 1.10
and
it's going both good and bad.
>
> The good thing is that new
interactive
conflict resolver works absolutely
brilliantly for text
conflicts. Great job everyone!
> The bad
news is that I can't resolve my tree
conflicts.
>
> Let me prefix this
with saying that the corporate svn
server I'm using is
badly setup and slow as molasses (*),
which may play a part
here, but even without that, I don't
understand the
behavior I am seeing. It is probably
correct as-is, but
unfortunately seems to make svn 1.10
impossible to use for
me.
>
> I'm
trying a merge from trunk to my branch
on a project with
this kind of chronology for a
conflict:
>
* branch created at r105778 (the file
"foo" exists
on trunk)
> * "foo" modified on
trunk in r106352
> * "foo"
moved and renamed on branch in
r106610
>
* merge trunk to branch in rev 107369
(first merge to the
branch)
>
> But when
it hits "foo" in the resolver, it
prints:
>
> Searching tree
conflict details for foo in
repository:
>
Checking r<xxx>...
>
> Where <xxx> started at
recent
changes in "foo" but is going
backwards to
> revisions long before the branch
root,
i.e. revisions before 105778. I don't
> understand how any of these
should affect
the merge resolution since they are
>
older than when I created the branch
so I'm guaranteed
to already have those
> revisions (?). I
even *think* it is continuing further
back than when the
foo
> was added to trunk. And this is
taking a really really long time with
our
> server. We're talking minutes
per
revision, even causing timeout from
the
>
server so I can't resolve the
conflict. Shouldn't it
have stopped going
> backwards beyond the
revisions that I branched off on?
(the
"--stop-on-copy"
>
revision)
Your
expectations are not unreasonable but
keep in mind that the
resolver
works in the context of one
particular file or directory. When it
traces
history back and traverses copies it
cannot
tell whether those copies
were creating a
new branch or copy an item within a
branch; in the data
model, these twoI cases look 100%
alike.
We will need a more concrete
example to confirm the problem and
if
possible fix the behaviour. Could you
try to write a script
which
starts by creating a fresh and empty
repository, adds files and
directories
as
necessary, and creates this specific
tree conflict situation
where it
traces history further back than
necessary? That would help us a lot.
As a workaround, if this is a blocking
issue
for you, you could run
problematic merges
with --non-interactive. This will
postpone all
conflicts and suppress the
interactive
resolver. This allows you to
resolve the
problematic conflict manually as you
would have done
in SVN 1.9. Once the problematic
conflict has
been resolved, you can
resolve all remaining
conflicts interactively by running
'svn resolve'.
Problems like this are not
expected but unfortunately not
inevitable either.
The resolver is new in this release
and has not
seen much real world testing,
even though we
gave the community some early
opportunities in form of
alpha
releases and release candidates.
Feedback such as yours is very much
appreciated because we cannot improve
the
resolver without it.
Thanks,
Stefan
-----Inline Attachment Follows-----
#!/bin/sh
##############################################################################
## ##
## This is a template for writing Subversion bug reproduction scripts. ##
## ##
## It creates a repository containing the standard Greek Tree (see ##
## http://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/greek-tree.txt) ##
## and checks out a working copy containing that tree. Please adjust ##
## this script however you need to to demonstrate your bug. When it's ##
## ready, post the bug report to d...@subversion.apache.org -- after ##
## http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs, ##
## of course. ##
## ##
##############################################################################
# You might need to adjust these lines to point to your
# compiled-from-source Subversion binaries, if using those:
if [ -z "$SVN" ]; then
SVN=`which svn`
SVNSERVE=`which svnserve`
SVNADMIN=`which svnadmin`
fi
# Make sure we don't use $HOME/.subversion/.
SVN="${SVN} --config-dir=`pwd`/svn-repro-config-dir"
SVNADMIN="${SVNADMIN} --config-dir=`pwd`/svn-repro-config-dir"
SVNSERVE="${SVNSERVE} --config-dir=`pwd`/svn-repro-config-dir"
# Use English output.
LC_ALL=C; export LC_ALL
# Select an access method. If svn://, the svnserve setup is
# handled automagically by this script; but if http://, then
# you'll have to configure it yourself first.
#
# URL=http://localhost/SOMETHING/repos
# URL=svn://localhost/repos
URL=file:///`pwd`/repos
if [ -e repos ]; then rm -rf repos; fi
if [ -e wc ]; then rm -rf wc; fi
if [ -e import-me ]; then rm -rf import-me; fi
${SVNADMIN} create repos
# These are for svnserve only.
#echo "[general]" > repos/conf/svnserve.conf
#echo "anon-access = write" >> repos/conf/svnserve.conf
#echo "auth-access = write" >> repos/conf/svnserve.conf
# The server will only be contacted if $URL is svn://foo, of course.
#${SVNSERVE} --pid-file svnserve-pid -d -r `pwd`
# And put the kill command in a file, in case need to run it manually.
#echo "kill -9 `cat svnserve-pid`" > k
#chmod a+rwx k
echo "### Making a Greek Tree for import..."
mkdir import-me
mkdir import-me/trunk
mkdir import-me/tags
mkdir import-me/branches
mkdir import-me/trunk/A
mkdir import-me/trunk/A/B/
mkdir import-me/trunk/A/C/
mkdir import-me/trunk/A/D/
mkdir import-me/trunk/A/B/E/
mkdir import-me/trunk/A/B/F/
mkdir import-me/trunk/A/D/G/
mkdir import-me/trunk/A/D/H/
echo "This is the file 'iota'." > import-me/trunk/iota
echo "This is the file 'A/mu'." > import-me/trunk/A/mu
echo "This is the file 'A/B/lambda'." > import-me/trunk/A/B/lambda
echo "This is the file 'A/B/E/alpha'." > import-me/trunk/A/B/E/alpha
echo "This is the file 'A/B/E/beta'." > import-me/trunk/A/B/E/beta
echo "This is the file 'A/D/gamma'." > import-me/trunk/A/D/gamma
echo "This is the file 'A/D/G/pi'." > import-me/trunk/A/D/G/pi
echo "This is the file 'A/D/G/rho'." > import-me/trunk/A/D/G/rho
echo "This is the file 'A/D/G/tau'." > import-me/trunk/A/D/G/tau
echo "This is the file 'A/D/H/chi'." > import-me/trunk/A/D/H/chi
echo "This is the file 'A/D/H/omega'." > import-me/trunk/A/D/H/omega
echo "This is the file 'A/D/H/psi'." > import-me/trunk/A/D/H/psi
echo "### Done."
echo ""
echo "### Importing it..."
(cd import-me; ${SVN} import -q -m "Initial import." ${URL})
echo "### Done."
echo ""
${SVN} co -q ${URL}/trunk wc
cd wc
echo "firstchange" >> testfile; ${SVN} add testfile; ${SVN} commit -m 'adding testfile in rev 2'
${SVN} copy -m 'Creating branch' ${URL}/trunk ${URL}/branches/branch1
echo "trunkchange" >> testfile; ${SVN} commit -m 'trunk modifying testfile'
${SVN} switch ${URL}/branches/branch1 .
${SVN} mv testfile foobar; ${SVN} commit -m 'moved testfile on branch'
${SVN} update
${SVN} merge ${URL}/trunk
cd ..
# Put kill command in a file, in case need to run it manually.
#echo "kill -9 `cat svnserve-pid`" > k
#chmod a+rwx k
#./k
