Skip Menu |
 

This queue is for tickets about the svk CPAN distribution.

Report information
The Basics
Id: 29945
Status: new
Priority: 0/
Queue: svk

People
Owner: Nobody in particular
Requestors: brice+bitcard [...] daysofwonder.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: v2.0.1
Fixed in: (no value)



Subject: svk:merge merge-ticket corruption
Download (untitled) / with headers
text/plain 4.1k
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.
From: brice+bitcard [...] daysofwonder.com
Just uploaded a synthetic testcase shell script
Download testsvk.sh
application/x-shellscript 1.1k

Message body not shown because it is not plain text.



This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.