| Subject: | svk:merge merge-ticket corruption |
Bug Description:
We are seeing lots of merge-ticket corruption (revision going backwards,
or missing merge-tickets) in svk:merge of an upstream SVN repository
after a combination of push/pull by different people.
Test-case 100% reproducible:
with svk version v2.0.1 (using Subversion bindings 1.4.4) on a debian
Sid box.
The testcase needs 2 shell sessions to reproduce, because it involves 2
depots.
1) Create the SVN upstream repository
$ svnadmin create repos
2) In session 1, create a depot, mirror the SVN, get a working copy and
produce some changes:
# create depot
$ export SVKROOT=`pwd`/depot1
$ svk mirror --list
Repository /home/brice/temp/test4/depot1/local does not exist, create?
(y/n)y
# mirror repos
$ svk mirror file://`pwd`/repos //mirror/repos
$ svk cp -p //mirror/repos //local/repos
Waiting for editor...
Committed revision 2.
$ svk co //local/repos wc1
Syncing //local/repos(/local/repos) in /home/brice/temp/test4/wc1 to 2.
# create content
$ cd wc1
$ echo "file 1" > file1.txt
$ svk add file1.txt
A file1.txt
$ svk commit -m "file1.txt"
Committed revision 3.
$ svk push -l
Auto-merging (0, 3) /local/repos to /mirror/repos (base /:0).
Merging back to mirror source file:///home/brice/temp/test4/repos.
A file1.txt
New merge ticket: 7ef76fb6-aafc-41db-b84c-45c96e11daaa:/local/repos:3
Merge back committed as revision 1.
3) In session 2, do the same:
export SVKROOT=`pwd`/depot2
$ svk mirror --list
Repository /home/brice/temp/test4/depot2/local does not exist, create?
(y/n)y
$ svk mirror file://`pwd`/repos //mirror/repos
Mirror initialized. Run svk sync //mirror/repos to start mirroring.
$ svk sync //mirror/repos
Syncing file:///home/brice/temp/test4/repos
$ svk cp -p //mirror/repos //local/repos
Waiting for editor...
Committed revision 2.
$ svk co //local/repos wc2
Syncing //local/repos(/local/repos) in /home/brice/temp/test4/wc2 to 2.
$ cd wc2
$ svk pull
Syncing file:///home/brice/temp/test4/repos
Retrieving log information from 1 to 1
Committed revision 3 from revision 1.
Auto-merging (1, 3) /mirror/repos to /local/repos
(base /mirror/repos:1).
A file1.txt
New merge ticket: 79e865fa-77c7-4d4f-a35f-2fb95158a337:/:1
New merge ticket: 7ef76fb6-aafc-41db-b84c-45c96e11daaa:/local/repos:3
Committed revision 4.
Syncing //local/repos(/local/repos) in /home/brice/temp/test4/wc2 to 4.
A file1.txt
$ echo "file2" > file2.txt
svk add file2.txt
A file2.txt
$ svk commit -m "file2"
Committed revision 5.
$ svk push -l
Auto-merging (0, 5) /local/repos to /mirror/repos
(base /mirror/repos:3).
Merging back to mirror source file:///home/brice/temp/test4/repos.
A file2.txt
New merge ticket: fd5f0c96-7712-4483-a41c-52005bba9c90:/local/repos:5
Merge back committed as revision 2.
Syncing file:///home/brice/temp/test4/repos
Retrieving log information from 2 to 2
Committed revision 6 from revision 2.
4) At this point, everything is still OK. Let's examine the
merge-tickets in the upstream SVN repository:
$ svn propget 'svk:merge' file:///home/brice/temp/test4/repos
7ef76fb6-aafc-41db-b84c-45c96e11daaa:/local/repos:3
fd5f0c96-7712-4483-a41c-52005bba9c90:/local/repos:5
5) Back in session 1, produce a change without a pull, and push it upstream:
$ echo "file3" >> file1.txt
$ svk commit -m "r2"
Committed revision 5.
$ svk push -l
Auto-merging (3, 5) /local/repos to /mirror/repos (base /local/repos:3).
Merging back to mirror source file:///home/brice/temp/test4/repos.
U file1.txt
New merge ticket: 7ef76fb6-aafc-41db-b84c-45c96e11daaa:/local/repos:5
Merge back committed as revision 3.
Syncing file:///home/brice/temp/test4/repos
Retrieving log information from 2 to 3
Committed revision 6 from revision 2.
Committed revision 7 from revision 3.
6) Let's examine the merge-tickets one more time:
$ svn propget 'svk:merge' file:///home/brice/temp/test4/repos
7ef76fb6-aafc-41db-b84c-45c96e11daaa:/local/repos:5
We lost the 'fd5f0c96-7712-4483-a41c-52005bba9c90:/local/repos:5'.
The last push should have failed.
I'm not sure SVK is at fault, it might well be a SVN bug, but SVK should
at least provide a safeguard because such behavior can produce strange
results (re-applying already merged changes or more complex things) when
the session 2 pulls or pushes next time.