subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Robinson <davidtrobin...@gmail.com>
Subject Possible bug in svn client 1.8 - svn merge does reintegrate when it should sync
Date Thu, 21 Aug 2014 14:47:06 GMT
Overview of problem:
Using svn client 1.8.10 on Mac OSX 10.9.4, downloaded from wandisco.

When trying to sync trunk to a branch with the command: svn merge ^/trunk
I get the following error:
svn merge ^/trunk
svn: E195016: Reintegrate can only be used if revisions 3 through 6 were
previously merged from
file:///Users/drobinson/svntest/repo/branches/branch1 to the reintegrate
source, but this is not the case:
  trunk
    Missing ranges: /branches/branch1:3

^/branches/branch1 is a copy of trunk that I made.  I added a file,
test2.txt, to ^/branches/branch1, switched to ^/trunk and added another
file, test3.txt, then cherry picked the revision from branch1 to get
test2.txt into trunk.  I then went to perform a sync merge on branch1 and
it is trying to reintegrate trunk into the branch instead of doing a sync
merge.

This is a contrived example that I am doing to verify a bug in the client.
 I experienced this problem in actual development when we had a bug fix
branch we were working in and we needed to merge a couple of bug fixes into
trunk from the branch but we were not ready to merge all of the bug fixes.
 When I tried to do a sync merge from trunk to get our branch up to date,
the client tried to do the reintegrate instead of the sync.  I reverted the
svn client to 1.7.17 because I knew in that version you have to explicitly
tell the client to reintegrate with the --reintegrate option.  I was able
to perform the sync merge after downgrading.

I believe this is a bug.  It appears to be caused by cherry pick merging
from the branch into trunk.  I know that this probably isn't a common
problem, but I could not find anything in the merge documentation about
cherry picking that indicated it would mess up a sync merge.  It seems like
the client should be able to detect that the working copy was copied from
trunk and that it should be doing a sync merge instead of a reintegrate.

Can anyone validate that this is a bug for me?

Thanks,

Dave Robinson

P.S. Here is the command history of me trying to reproduce the bug:
590  svnadmin create repo
591  mkdir -p trunk/myProject
592  cd trunk/myProject/
593  vi test.txt
594  cd ../../
596  svn import trunk file:///Users/drobinson/svntest/repo/trunk
598  rm -r trunk/
601  svn co file:///Users/drobinson/svntest/repo/trunk
602  cd trunk/
605  svn mkdir ^/branches -m "making branches dir"
606  svn copy ^/trunk ^/branches/branch1 -m "making branch1 for testing"
608  svn switch ^/branches/branch1
610  cd myProject/
612  vi test2.txt
613  svn add test2.txt
614  svn commit -m "added test2.txt in branch1"
615  cd ..
616  svn up
617  svn switch ^/trunk
618  cd myProject/
620  vi test3.txt
621  svn add test3.txt
622  svn commit -m "added test3.txt in trunk"
624  cd ..
625  svn up
626  svn log ^/branches/branch1
627  svn up
628  svn merge -c 4 ^/branches/branch1
629  svn commit -m "cherry pick merged revision 4 from branch1"
630  svn up
631  svn switch ^/branches/branch1
632  svn up
633  svn merge ^/trunk
--At this point I get the following error:
svn: E195016: Reintegrate can only be used if revisions 3 through 6 were
previously merged from
file:///Users/drobinson/svntest/repo/branches/branch1 to the reintegrate
source, but this is not the case:
  trunk
    Missing ranges: /branches/branch1:3

Mime
View raw message