Heya,
While converting a mildly complicated svn repository that was managed
with SVK, I ran across the following oddness. `svk smerge` can only
merge between _two_ branches at once -- however, the way that svk
merge detection works, you can end up with erroneous extra parents
from long-dead branches. Case in point:
export SVKROOT=/tmp/svk-testing-$$
svk mkdir //trunk -m 'trunk'
svk mkdir //branches -m 'branches'
svk co //trunk
svk cp //trunk/ //branches/feature1 -m 'branch for feature1'
svk cp //trunk/ //branches/feature2 -m 'branch for feature2'
svk co //branches/feature1
cd feature1
echo "foo" >foo
svk add foo
svk ci -m 'feature1 development'
svk sm //branches/feature1 //trunk -m 'merge feature1 to trunk'
cd ..
svk co //branches/feature2
cd feature2
echo "bar" >bar
svk add bar
svk ci -m 'feature2 development'
svk sm //trunk //branches/feature2 -m 'merge from trunk'
cd ..
git svn clone -s file://$SVKROOT/local
The 'feature2' branch will appear to have three parents: r7, r6, _and_
r5. The r5 parent is extraneous, and only appears because r5 was
previously merged into trunk, as part of r6.
Given this, I'm a little confused why find_extra_svk_parents is
written the way that it is, in seemingly allowing multiple extra
parents to be found. Since the most recent (i.e., highest-numbered)
change is by definition the only one that can account for all of the
other svk:merge changes, I _believe_ the attached diff to be correct,
but I'm unsure because of the implicit current assumption that smerges
can produce multiple parents.
- Alex
--
Networking -- only one letter away from not working
Attachment:
0001-git-svn-svk-merge-commits-should-only-add-one-exta-p.patch
Description: Binary data