You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alan Spencer <al...@rockalltech.com> on 2009/12/17 10:37:23 UTC
Probable bug with svn copy
Hi All,
I've been asked to analyse a problem we have had with subversion and
come to the conclusion there is a bug in at least the client.
The scenario was someone committed a new directory that made a build
fail and in order to free up the build this commit was reverse merges
(merge -c -RRRR)
The individual in question wanted their changes back and the opportunity
to fix the problem. This was done by reverse merging the reverse merge.
They then fixed the problems, which included renaming a file.
They then committed these changes and updated and all looked OK.
Updating on other working copy showed that both the original and renamed
file existed, but the working copy used did not show this.
I wanted to find out if this is user error or a bug and if it has been
logged already.
And is there a way to achieve this without hitting this problem.
Here is a log of my reproducing this:
SETUP:
------------------
C:\dev\projects\build\build>mkdir svn-experiments
C:\dev\projects\build\build>svn add svn-experiments
A svn-experiments
C:\dev\projects\build\build>cd svn-experiments
C:\dev\projects\build\build\svn-experiments>mkdir experiment-1
C:\dev\projects\build\build\svn-experiments>cd experiment-1
C:\dev\projects\build\build\svn-experiments\experiment-1>notepad
readme.txt
C:\dev\projects\build\build\svn-experiments\experiment-1>mkdir
systemtest
C:\dev\projects\build\build\svn-experiments\experiment-1>cd ..
C:\dev\projects\build\build\svn-experiments>svn add experiment-1
A experiment-1
A experiment-1\readme.txt
A experiment-1\systemtest
C:\dev\projects\build\build\svn-experiments>cd ..
C:\dev\projects\build\build>svn commit -m "SVN experimentation area"
svn-experiments
Adding svn-experiments
Adding svn-experiments\experiment-1
Adding svn-experiments\experiment-1\readme.txt
Adding svn-experiments\experiment-1\systemtest
Transmitting file data .
Committed revision 16664.
C:\dev\projects\build\build>cd svn-experiments\experiment-1\systemtest
INITIAL CHANGE:
---------------------------
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest>mkdi
r audit
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest>cd
audit
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest\audi
t>notepad FirstName.txt
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest\audi
t>cd ..
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest>svn
status
? audit
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest>svn
add audit
A audit
A audit\FirstName.txt
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest>cd
..
C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
"First Add"
Adding experiment-1\systemtest\audit
Adding experiment-1\systemtest\audit\FirstName.txt
Transmitting file data .
Committed revision 16665.
NOW REVERSE MERGE CHANGE
------------------------------------------------------
C:\dev\projects\build\build\svn-experiments\experiment-1>svn merge -c
-16665 .
svn: Cannot reverse-merge a range from a path's own future history; try
updating first
C:\dev\projects\build\build\svn-experiments\experiment-1>svn up
At revision 16665.
C:\dev\projects\build\build\svn-experiments\experiment-1>svn merge -c
-16665 .
--- Reverse-merging r16665 into '.':
D systemtest\audit
C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
"Reverting svn merge -c -16665 ." systemtest\audit
Deleting systemtest\audit
Committed revision 16666.
NOW REVERSE MERGE THE REVERSE MERGE
------------------------------------------------------------------------
---
C:\dev\projects\build\build\svn-experiments\experiment-1>svn merge -c
-16666 .
svn: Cannot reverse-merge a range from a path's own future history; try
updating first
C:\dev\projects\build\build\svn-experiments\experiment-1>svn up
At revision 16666.
C:\dev\projects\build\build\svn-experiments\experiment-1>svn merge -c
-16666 .
--- Reverse-merging r16666 into '.':
A systemtest\audit
A systemtest\audit\FirstName.txt
RENAME THE ADDED FILE
------------------------------------------
C:\dev\projects\build\build\svn-experiments\experiment-1>svn move
systemtest\audit\FirstName.txt systemtest\audit\SecondName.txt
A systemtest\audit\SecondName.txt
D systemtest\audit\FirstName.txt
C:\dev\projects\build\build\svn-experiments\experiment-1>dir
systemtest\audit\
Volume in drive C has no label.
Volume Serial Number is 24AC-D508
Directory of
C:\dev\projects\build\build\svn-experiments\experiment-1\systemtest\audi
t
17/12/2009 09:53 <DIR> .
17/12/2009 09:53 <DIR> ..
17/12/2009 09:53 31 SecondName.txt
1 File(s) 31 bytes
2 Dir(s) 410,323,771,392 bytes free
C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
"Revert revert and renaming svn merge -c -16666 . svn move
systemtest\audit\FirstName.txt systemtest\audit\SecondName.txt" .
Adding experiment-1\systemtest\audit
Adding experiment-1\systemtest\audit\SecondName.txt
Committed revision 16667.
C:\dev\projects\build\build\svn-experiments\experiment-1>
UPDATE ELSEWHERE
----------------------------------
C:\dev\CO\trunk>svn up build\svn-experiments\experiment-1\
A build\svn-experiments\experiment-1\systemtest\audit
A build\svn-experiments\experiment-1\systemtest\audit\FirstName.txt
A build\svn-experiments\experiment-1\systemtest\audit\SecondName.txt
Updated to revision 16667.
Many Thanks,
Alan.
Re: Probable bug with svn copy
Posted by Julian Foad <ju...@btopenworld.com>.
Hyrum K. Wright wrote:
> On Jan 25, 2010, at 1:17 AM, Noorul Islam K M wrote:
> > @@ -4352,7 +4390,8 @@
> > path_copy_in_repo_2475,
> > commit_copy_depth_empty,
> > copy_below_copy,
> > - XFail(move_below_move)
> > + XFail(move_below_move),
> > + XFail(reverse_merge_move)
>
> Haven't reviewed the patch, but there should be a comma at the end of
> this line (there wasn't one on the previous terminal item, but Python
> allows it, and we try to use it to avoid churn).
I'll add a comma when I commit it, if I commit it. No need to re-send
the patch just for that. But thanks for noticing.
- Julian
> > ]
> >
> > if __name__ == '__main__':
Re: Probable bug with svn copy
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Jan 25, 2010, at 1:17 AM, Noorul Islam K M wrote:
>
>> On Thu, 2009-12-17, Alan Spencer wrote:
>>> I've been asked to analyse a problem we have had with subversion and
>>> come to the conclusion there is a bug in at least the client.
>>>
>>>
>>> The scenario was someone committed a new directory that made a build
>>> fail and in order to free up the build this commit was reverse merges
>>> (merge -c -RRRR)
>>>
>>> The individual in question wanted their changes back and the opportunity
>>> to fix the problem. This was done by reverse merging the reverse merge.
>>>
>>> They then fixed the problems, which included renaming a file.
>>>
>>> They then committed these changes and updated and all looked OK.
>>>
>>> Updating on other working copy showed that both the original and renamed
>>> file existed, but the working copy used did not show this.
>>>
>>>
>>>
>>> I wanted to find out if this is user error or a bug and if it has been
>>> logged already.
>>
>> This certainly looks like a bug. It sounds familiar, but I can't find it
>> in the issue tracker.
>>
>>> And is there a way to achieve this without hitting this problem.
>>
>> I'm not sure.
>>
>>
>>> Here is a log of my reproducing this:
>> [...]
>>> C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
>>> "Revert revert and renaming svn merge -c -16666 . svn move
>>> systemtest\audit\FirstName.txt systemtest\audit\SecondName.txt" .
>>> Adding experiment-1\systemtest\audit
>>> Adding experiment-1\systemtest\audit\SecondName.txt
>>> Committed revision 16667.
>>
>> With a release candidate for 1.6.8, using the attached script, I get the
>> same result as you.
>>
>> With a trunk build (r898816), using the attached script, I get a
>> different problem here: the commit sort of fails:
>>
>> + svn commit -m 'Revert revert and renaming svn merge -c -16666 . svn
>> move systemtest/audit/FirstName.txt systemtest/audit/SecondName.txt' .
>> Adding experiment-1/systemtest/audit
>> Deleting experiment-1/systemtest/audit/FirstName.txt
>> Adding experiment-1/systemtest/audit/SecondName.txt
>> svn: Commit succeeded, but other errors follow:
>> svn: Error bumping revisions post-commit (details follow):
>> svn: The node 'FirstName.txt' was not found.
>>
>> This is interesting, and it would be good to turn this script into a
>> test in the test suite so that we remember to fix the bug. Any
>> volunteers?
>>
>
> Julian,
>
> Please find attached test case patch for this scenario in trunk.
>
> [[[
> Log:
>
> New XFail test case for reverse merge move scenario. Rename fails after
> reverting a commit using reverse merge. This issue need to be fixed for
> the test case to pass.
>
> * subversion/tests/cmdline/copy_tests.py
> (reverse_merge_move): New function.
> (test_list): Added test.
>
> Found by: alan.spencer
> Suggested by: julianfoad
> Patch by: Noorul Islam K M <no...@collab.net>
> ]]]
>
>
> Thanks and Regards
> Noorul
> Index: copy_tests.py
> ===================================================================
> --- copy_tests.py (revision 902715)
> +++ copy_tests.py (working copy)
> @@ -4266,6 +4266,44 @@
> None, sbox.wc_dir)
>
>
> +def reverse_merge_move(sbox):
> + """reverse merge move"""
> +
> + # Alias for svntest.actions.run_and_verify_svn
> + rav_svn = svntest.actions.run_and_verify_svn
> +
> + wc_dir = sbox.wc_dir
> + a_dir = os.path.join(wc_dir, 'A')
> + a_repo_url = sbox.repo_url+ '/A'
> + sbox.build()
> +
> + # Update working directory and ensure that we are at revision 1.
> + rav_svn(None, ["At revision 1.\n"], [], 'up', wc_dir)
> +
> + # Add new folder and file, later commit
> + new_path = os.path.join(a_dir, 'New')
> + os.mkdir(new_path)
> + first_path = os.path.join(new_path, 'first')
> + svntest.main.file_append(first_path, 'appended first text')
> + svntest.main.run_svn(None, "add", new_path)
> + rav_svn(None, None, [], 'ci', wc_dir, '-m', 'Add new folder %s' % new_path)
> + rav_svn(None, ["At revision 2.\n"], [], 'up', wc_dir)
> +
> + # Reverse merge to revert previous changes and commit
> + rav_svn(None, None, [], 'merge', '-c', '-2', a_repo_url, a_dir)
> + rav_svn(None, None, [], 'ci', '-m', 'Reverting svn merge -c -2.', a_dir)
> + rav_svn(None, ["At revision 3.\n"], [], 'up', wc_dir)
> +
> + # Reverse merge again to undo last revert.
> + rav_svn(None, None, [], 'merge', '-c', '-3', a_repo_url, a_dir)
> +
> + # Move new added file to another one and commit.
> + second_path = os.path.join(new_path, 'second')
> + rav_svn(None, None, [], 'move', first_path, second_path)
> + rav_svn(None, None, ["Committed revision 4.\n"], 'ci', '-m',
> + 'Revert svn merge. svn mv %s %s.' % (first_path, second_path), a_dir)
> +
> +
> ########################################################################
> # Run the tests
>
> @@ -4352,7 +4390,8 @@
> path_copy_in_repo_2475,
> commit_copy_depth_empty,
> copy_below_copy,
> - XFail(move_below_move)
> + XFail(move_below_move),
> + XFail(reverse_merge_move)
Haven't reviewed the patch, but there should be a comma at the end of this line (there wasn't one on the previous terminal item, but Python allows it, and we try to use it to avoid churn).
> ]
>
> if __name__ == '__main__':
-Hyrum
Re: Probable bug with svn copy
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2010-01-26, Noorul Islam K M wrote:
> Julian Foad <ju...@btopenworld.com> writes:
> > Paul Burba wrote:
> >> Also, would you mind taking a stab at expanding the test to cover
> >> Alan's original problem? Specifically that a second working copy,
> >> when updated, gets both the move destination *and* the source added.
> >
> > Or a separate test - either way would be really helpful.
>
> Please find attached the test case patch for the actual scenario that
> Alan explains in his mail.
>
> This patch is created against r899215 because trunk has different
> behavior during commit.
Thank you, Noorul.
I think you mean the patch is against the 1.6.x branch. (A revision
number by itself doesn't indicate a branch.) That's fine, and the
easiest way to test it. However, I am going to apply it to the trunk
first, because it is useful as a regression test on trunk anyway (even
if the bug doesn't currently exist on trunk) and because that is the
usual way. We can back-port it to the 1.6.x branch afterwards.
I am also going to combine this extra check into the first test
function, like Paul suggested. (I thought the two tests might be rather
different but this is simply an extension to the first test.)
Committed in r904072.
Thanks for writing the tests, and the log message (although I decided to
change it a bit).
- Julian
Re: Probable bug with svn copy
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2010-01-26, Noorul Islam K M wrote:
> Julian Foad <ju...@btopenworld.com> writes:
> > Paul Burba wrote:
> >> Also, would you mind taking a stab at expanding the test to cover
> >> Alan's original problem? Specifically that a second working copy,
> >> when updated, gets both the move destination *and* the source added.
> >
> > Or a separate test - either way would be really helpful.
>
> Please find attached the test case patch for the actual scenario that
> Alan explains in his mail.
>
> This patch is created against r899215 because trunk has different
> behavior during commit.
Thank you, Noorul.
I think you mean the patch is against the 1.6.x branch. (A revision
number by itself doesn't indicate a branch.) That's fine, and the
easiest way to test it. However, I am going to apply it to the trunk
first, because it is useful as a regression test on trunk anyway (even
if the bug doesn't currently exist on trunk) and because that is the
usual way. We can back-port it to the 1.6.x branch afterwards.
I am also going to combine this extra check into the first test
function, like Paul suggested. (I thought the two tests might be rather
different but this is simply an extension to the first test.)
Committed in r904072.
Thanks for writing the tests, and the log message (although I decided to
change it a bit).
- Julian
Re: Probable bug with svn copy
Posted by Noorul Islam K M <no...@collab.net>.
Julian Foad <ju...@btopenworld.com> writes:
> Paul Burba wrote:
>> On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M <no...@collab.net> wrote:
>> > + # Move new added file to another one and commit.
>> > + second_path = os.path.join(new_path, 'second')
>> > + rav_svn(None, None, [], 'move', first_path, second_path)
>> > + rav_svn(None, None, ["Committed revision 4.\n"], 'ci', '-m',
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> The expected_stderr is "", not "Committed revision 4.\n". The
>> expected_stdout is something like:
>>
>> [[[
>> Adding svn-test-work\working_copies\copy_tests-77\A\New
>> Adding svn-test-work\working_copies\copy_tests-77\A\New\second
>>
>> Committed revision 4.
>> ]]]
>>
>> So you can either pass None as expected_stdout (in which case it isn't
>> checked at all), pass a single string regex describing the above
>> output, or use svntest.actions.run_and_verify_commit().
>
> Oops, sorry, I already committed it in r902841. I'll change that or at
> least add a comment.
>
Thank you, for changing it.
>> Also, would you mind taking a stab at expanding the test to cover
>> Alan's original problem? Specifically that a second working copy,
>> when updated, gets both the move destination *and* the source added.
>
> Or a separate test - either way would be really helpful.
>
Please find attached the test case patch for the actual scenario that
Alan explains in his mail.
This patch is created against r899215 because trunk has different
behavior during commit.
[[[
Log:
New XFail test case for reverse merge, move and update second
working copy scenario. The second working copy update gets both
the move destination and the source added. This issue needs to be
fixed for the test case to pass.
See the email thread
<http://svn.haxx.se/dev/archive-2009-12/0347.shtml>.
* subversion/tests/cmdline/copy_tests.py
(reverse_merge_move_update_wc2): New function.
(test_list): Added test.
Found by: alan.spencer
Suggested by: julianfoad
Patch by: Noorul Islam K M <noorul{_AT_}collab.net>
]]]
Thanks and Regards
Noorul
Re: Probable bug with svn copy
Posted by Noorul Islam K M <no...@collab.net>.
Julian Foad <ju...@btopenworld.com> writes:
> Paul Burba wrote:
>> On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M <no...@collab.net> wrote:
>> > + # Move new added file to another one and commit.
>> > + second_path = os.path.join(new_path, 'second')
>> > + rav_svn(None, None, [], 'move', first_path, second_path)
>> > + rav_svn(None, None, ["Committed revision 4.\n"], 'ci', '-m',
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> The expected_stderr is "", not "Committed revision 4.\n". The
>> expected_stdout is something like:
>>
>> [[[
>> Adding svn-test-work\working_copies\copy_tests-77\A\New
>> Adding svn-test-work\working_copies\copy_tests-77\A\New\second
>>
>> Committed revision 4.
>> ]]]
>>
>> So you can either pass None as expected_stdout (in which case it isn't
>> checked at all), pass a single string regex describing the above
>> output, or use svntest.actions.run_and_verify_commit().
>
> Oops, sorry, I already committed it in r902841. I'll change that or at
> least add a comment.
>
Thank you, for changing it.
>> Also, would you mind taking a stab at expanding the test to cover
>> Alan's original problem? Specifically that a second working copy,
>> when updated, gets both the move destination *and* the source added.
>
> Or a separate test - either way would be really helpful.
>
Please find attached the test case patch for the actual scenario that
Alan explains in his mail.
This patch is created against r899215 because trunk has different
behavior during commit.
[[[
Log:
New XFail test case for reverse merge, move and update second
working copy scenario. The second working copy update gets both
the move destination and the source added. This issue needs to be
fixed for the test case to pass.
See the email thread
<http://svn.haxx.se/dev/archive-2009-12/0347.shtml>.
* subversion/tests/cmdline/copy_tests.py
(reverse_merge_move_update_wc2): New function.
(test_list): Added test.
Found by: alan.spencer
Suggested by: julianfoad
Patch by: Noorul Islam K M <noorul{_AT_}collab.net>
]]]
Thanks and Regards
Noorul
Re: Probable bug with svn copy
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
> On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M <no...@collab.net> wrote:
> > + # Move new added file to another one and commit.
> > + second_path = os.path.join(new_path, 'second')
> > + rav_svn(None, None, [], 'move', first_path, second_path)
> > + rav_svn(None, None, ["Committed revision 4.\n"], 'ci', '-m',
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The expected_stderr is "", not "Committed revision 4.\n". The
> expected_stdout is something like:
>
> [[[
> Adding svn-test-work\working_copies\copy_tests-77\A\New
> Adding svn-test-work\working_copies\copy_tests-77\A\New\second
>
> Committed revision 4.
> ]]]
>
> So you can either pass None as expected_stdout (in which case it isn't
> checked at all), pass a single string regex describing the above
> output, or use svntest.actions.run_and_verify_commit().
Oops, sorry, I already committed it in r902841. I'll change that or at
least add a comment.
> Also, would you mind taking a stab at expanding the test to cover
> Alan's original problem? Specifically that a second working copy,
> when updated, gets both the move destination *and* the source added.
Or a separate test - either way would be really helpful.
- Julian
Re: Probable bug with svn copy
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
> On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M <no...@collab.net> wrote:
> > + # Move new added file to another one and commit.
> > + second_path = os.path.join(new_path, 'second')
> > + rav_svn(None, None, [], 'move', first_path, second_path)
> > + rav_svn(None, None, ["Committed revision 4.\n"], 'ci', '-m',
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The expected_stderr is "", not "Committed revision 4.\n". The
> expected_stdout is something like:
>
> [[[
> Adding svn-test-work\working_copies\copy_tests-77\A\New
> Adding svn-test-work\working_copies\copy_tests-77\A\New\second
>
> Committed revision 4.
> ]]]
>
> So you can either pass None as expected_stdout (in which case it isn't
> checked at all), pass a single string regex describing the above
> output, or use svntest.actions.run_and_verify_commit().
Oops, sorry, I already committed it in r902841. I'll change that or at
least add a comment.
> Also, would you mind taking a stab at expanding the test to cover
> Alan's original problem? Specifically that a second working copy,
> when updated, gets both the move destination *and* the source added.
Or a separate test - either way would be really helpful.
- Julian
Re: Probable bug with svn copy
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M <no...@collab.net> wrote:
>
> Julian,
>
> Please find attached test case patch for this scenario in trunk.
>
> [[[
> Log:
>
> New XFail test case for reverse merge move scenario. Rename fails after
> reverting a commit using reverse merge. This issue need to be fixed for
> the test case to pass.
>
> * subversion/tests/cmdline/copy_tests.py
> (reverse_merge_move): New function.
> (test_list): Added test.
>
> Found by: alan.spencer
> Suggested by: julianfoad
> Patch by: Noorul Islam K M <no...@collab.net>
> ]]]
>
>
> Thanks and Regards
> Noorul
> Index: copy_tests.py
> ===================================================================
> --- copy_tests.py (revision 902715)
> +++ copy_tests.py (working copy)
> @@ -4266,6 +4266,44 @@
> None, sbox.wc_dir)
>
>
> +def reverse_merge_move(sbox):
> + """reverse merge move"""
> +
> + # Alias for svntest.actions.run_and_verify_svn
> + rav_svn = svntest.actions.run_and_verify_svn
> +
> + wc_dir = sbox.wc_dir
> + a_dir = os.path.join(wc_dir, 'A')
> + a_repo_url = sbox.repo_url+ '/A'
> + sbox.build()
> +
> + # Update working directory and ensure that we are at revision 1.
> + rav_svn(None, ["At revision 1.\n"], [], 'up', wc_dir)
> +
> + # Add new folder and file, later commit
> + new_path = os.path.join(a_dir, 'New')
> + os.mkdir(new_path)
> + first_path = os.path.join(new_path, 'first')
> + svntest.main.file_append(first_path, 'appended first text')
> + svntest.main.run_svn(None, "add", new_path)
> + rav_svn(None, None, [], 'ci', wc_dir, '-m', 'Add new folder %s' % new_path)
> + rav_svn(None, ["At revision 2.\n"], [], 'up', wc_dir)
> +
> + # Reverse merge to revert previous changes and commit
> + rav_svn(None, None, [], 'merge', '-c', '-2', a_repo_url, a_dir)
> + rav_svn(None, None, [], 'ci', '-m', 'Reverting svn merge -c -2.', a_dir)
> + rav_svn(None, ["At revision 3.\n"], [], 'up', wc_dir)
> +
> + # Reverse merge again to undo last revert.
> + rav_svn(None, None, [], 'merge', '-c', '-3', a_repo_url, a_dir)
> +
> + # Move new added file to another one and commit.
> + second_path = os.path.join(new_path, 'second')
> + rav_svn(None, None, [], 'move', first_path, second_path)
> + rav_svn(None, None, ["Committed revision 4.\n"], 'ci', '-m',
^^^^^^^^^^^^^^^^^^^^^^^^^
The expected_stderr is "", not "Committed revision 4.\n". The
expected_stdout is something like:
[[[
Adding svn-test-work\working_copies\copy_tests-77\A\New
Adding svn-test-work\working_copies\copy_tests-77\A\New\second
Committed revision 4.
]]]
So you can either pass None as expected_stdout (in which case it isn't
checked at all), pass a single string regex describing the above
output, or use svntest.actions.run_and_verify_commit().
Also, would you mind taking a stab at expanding the test to cover
Alan's original problem? Specifically that a second working copy,
when updated, gets both the move destination *and* the source added.
Paul
> + 'Revert svn merge. svn mv %s %s.' % (first_path, second_path), a_dir)
> +
> +
> ########################################################################
> # Run the tests
>
> @@ -4352,7 +4390,8 @@
> path_copy_in_repo_2475,
> commit_copy_depth_empty,
> copy_below_copy,
> - XFail(move_below_move)
> + XFail(move_below_move),
> + XFail(reverse_merge_move)
> ]
>
> if __name__ == '__main__':
>
Re: Probable bug with svn copy
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Jan 25, 2010 at 2:17 AM, Noorul Islam K M <no...@collab.net> wrote:
>
> Julian,
>
> Please find attached test case patch for this scenario in trunk.
>
> [[[
> Log:
>
> New XFail test case for reverse merge move scenario. Rename fails after
> reverting a commit using reverse merge. This issue need to be fixed for
> the test case to pass.
>
> * subversion/tests/cmdline/copy_tests.py
> (reverse_merge_move): New function.
> (test_list): Added test.
>
> Found by: alan.spencer
> Suggested by: julianfoad
> Patch by: Noorul Islam K M <no...@collab.net>
> ]]]
>
>
> Thanks and Regards
> Noorul
> Index: copy_tests.py
> ===================================================================
> --- copy_tests.py (revision 902715)
> +++ copy_tests.py (working copy)
> @@ -4266,6 +4266,44 @@
> None, sbox.wc_dir)
>
>
> +def reverse_merge_move(sbox):
> + """reverse merge move"""
> +
> + # Alias for svntest.actions.run_and_verify_svn
> + rav_svn = svntest.actions.run_and_verify_svn
> +
> + wc_dir = sbox.wc_dir
> + a_dir = os.path.join(wc_dir, 'A')
> + a_repo_url = sbox.repo_url+ '/A'
> + sbox.build()
> +
> + # Update working directory and ensure that we are at revision 1.
> + rav_svn(None, ["At revision 1.\n"], [], 'up', wc_dir)
> +
> + # Add new folder and file, later commit
> + new_path = os.path.join(a_dir, 'New')
> + os.mkdir(new_path)
> + first_path = os.path.join(new_path, 'first')
> + svntest.main.file_append(first_path, 'appended first text')
> + svntest.main.run_svn(None, "add", new_path)
> + rav_svn(None, None, [], 'ci', wc_dir, '-m', 'Add new folder %s' % new_path)
> + rav_svn(None, ["At revision 2.\n"], [], 'up', wc_dir)
> +
> + # Reverse merge to revert previous changes and commit
> + rav_svn(None, None, [], 'merge', '-c', '-2', a_repo_url, a_dir)
> + rav_svn(None, None, [], 'ci', '-m', 'Reverting svn merge -c -2.', a_dir)
> + rav_svn(None, ["At revision 3.\n"], [], 'up', wc_dir)
> +
> + # Reverse merge again to undo last revert.
> + rav_svn(None, None, [], 'merge', '-c', '-3', a_repo_url, a_dir)
> +
> + # Move new added file to another one and commit.
> + second_path = os.path.join(new_path, 'second')
> + rav_svn(None, None, [], 'move', first_path, second_path)
> + rav_svn(None, None, ["Committed revision 4.\n"], 'ci', '-m',
^^^^^^^^^^^^^^^^^^^^^^^^^
The expected_stderr is "", not "Committed revision 4.\n". The
expected_stdout is something like:
[[[
Adding svn-test-work\working_copies\copy_tests-77\A\New
Adding svn-test-work\working_copies\copy_tests-77\A\New\second
Committed revision 4.
]]]
So you can either pass None as expected_stdout (in which case it isn't
checked at all), pass a single string regex describing the above
output, or use svntest.actions.run_and_verify_commit().
Also, would you mind taking a stab at expanding the test to cover
Alan's original problem? Specifically that a second working copy,
when updated, gets both the move destination *and* the source added.
Paul
> + 'Revert svn merge. svn mv %s %s.' % (first_path, second_path), a_dir)
> +
> +
> ########################################################################
> # Run the tests
>
> @@ -4352,7 +4390,8 @@
> path_copy_in_repo_2475,
> commit_copy_depth_empty,
> copy_below_copy,
> - XFail(move_below_move)
> + XFail(move_below_move),
> + XFail(reverse_merge_move)
> ]
>
> if __name__ == '__main__':
>
Re: Probable bug with svn copy
Posted by Noorul Islam K M <no...@collab.net>.
> On Thu, 2009-12-17, Alan Spencer wrote:
>> I've been asked to analyse a problem we have had with subversion and
>> come to the conclusion there is a bug in at least the client.
>>
>>
>> The scenario was someone committed a new directory that made a build
>> fail and in order to free up the build this commit was reverse merges
>> (merge -c -RRRR)
>>
>> The individual in question wanted their changes back and the opportunity
>> to fix the problem. This was done by reverse merging the reverse merge.
>>
>> They then fixed the problems, which included renaming a file.
>>
>> They then committed these changes and updated and all looked OK.
>>
>> Updating on other working copy showed that both the original and renamed
>> file existed, but the working copy used did not show this.
>>
>>
>>
>> I wanted to find out if this is user error or a bug and if it has been
>> logged already.
>
> This certainly looks like a bug. It sounds familiar, but I can't find it
> in the issue tracker.
>
>> And is there a way to achieve this without hitting this problem.
>
> I'm not sure.
>
>
>> Here is a log of my reproducing this:
> [...]
>> C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
>> "Revert revert and renaming svn merge -c -16666 . svn move
>> systemtest\audit\FirstName.txt systemtest\audit\SecondName.txt" .
>> Adding experiment-1\systemtest\audit
>> Adding experiment-1\systemtest\audit\SecondName.txt
>> Committed revision 16667.
>
> With a release candidate for 1.6.8, using the attached script, I get the
> same result as you.
>
> With a trunk build (r898816), using the attached script, I get a
> different problem here: the commit sort of fails:
>
> + svn commit -m 'Revert revert and renaming svn merge -c -16666 . svn
> move systemtest/audit/FirstName.txt systemtest/audit/SecondName.txt' .
> Adding experiment-1/systemtest/audit
> Deleting experiment-1/systemtest/audit/FirstName.txt
> Adding experiment-1/systemtest/audit/SecondName.txt
> svn: Commit succeeded, but other errors follow:
> svn: Error bumping revisions post-commit (details follow):
> svn: The node 'FirstName.txt' was not found.
>
> This is interesting, and it would be good to turn this script into a
> test in the test suite so that we remember to fix the bug. Any
> volunteers?
>
Julian,
Please find attached test case patch for this scenario in trunk.
[[[
Log:
New XFail test case for reverse merge move scenario. Rename fails after
reverting a commit using reverse merge. This issue need to be fixed for
the test case to pass.
* subversion/tests/cmdline/copy_tests.py
(reverse_merge_move): New function.
(test_list): Added test.
Found by: alan.spencer
Suggested by: julianfoad
Patch by: Noorul Islam K M <no...@collab.net>
]]]
Thanks and Regards
Noorul
Re: Probable bug with svn copy
Posted by Noorul Islam K M <no...@collab.net>.
> On Thu, 2009-12-17, Alan Spencer wrote:
>> I've been asked to analyse a problem we have had with subversion and
>> come to the conclusion there is a bug in at least the client.
>>
>>
>> The scenario was someone committed a new directory that made a build
>> fail and in order to free up the build this commit was reverse merges
>> (merge -c -RRRR)
>>
>> The individual in question wanted their changes back and the opportunity
>> to fix the problem. This was done by reverse merging the reverse merge.
>>
>> They then fixed the problems, which included renaming a file.
>>
>> They then committed these changes and updated and all looked OK.
>>
>> Updating on other working copy showed that both the original and renamed
>> file existed, but the working copy used did not show this.
>>
>>
>>
>> I wanted to find out if this is user error or a bug and if it has been
>> logged already.
>
> This certainly looks like a bug. It sounds familiar, but I can't find it
> in the issue tracker.
>
>> And is there a way to achieve this without hitting this problem.
>
> I'm not sure.
>
>
>> Here is a log of my reproducing this:
> [...]
>> C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
>> "Revert revert and renaming svn merge -c -16666 . svn move
>> systemtest\audit\FirstName.txt systemtest\audit\SecondName.txt" .
>> Adding experiment-1\systemtest\audit
>> Adding experiment-1\systemtest\audit\SecondName.txt
>> Committed revision 16667.
>
> With a release candidate for 1.6.8, using the attached script, I get the
> same result as you.
>
> With a trunk build (r898816), using the attached script, I get a
> different problem here: the commit sort of fails:
>
> + svn commit -m 'Revert revert and renaming svn merge -c -16666 . svn
> move systemtest/audit/FirstName.txt systemtest/audit/SecondName.txt' .
> Adding experiment-1/systemtest/audit
> Deleting experiment-1/systemtest/audit/FirstName.txt
> Adding experiment-1/systemtest/audit/SecondName.txt
> svn: Commit succeeded, but other errors follow:
> svn: Error bumping revisions post-commit (details follow):
> svn: The node 'FirstName.txt' was not found.
>
> This is interesting, and it would be good to turn this script into a
> test in the test suite so that we remember to fix the bug. Any
> volunteers?
>
Julian,
Please find attached test case patch for this scenario in trunk.
[[[
Log:
New XFail test case for reverse merge move scenario. Rename fails after
reverting a commit using reverse merge. This issue need to be fixed for
the test case to pass.
* subversion/tests/cmdline/copy_tests.py
(reverse_merge_move): New function.
(test_list): Added test.
Found by: alan.spencer
Suggested by: julianfoad
Patch by: Noorul Islam K M <no...@collab.net>
]]]
Thanks and Regards
Noorul
Re: Probable bug with svn copy
Posted by Julian Foad <ju...@btopenworld.com>.
Hi Alan.
Thanks for this report, and sorry for the long time to respond.
I finally got around to converting your recipe into an executable script
(on Linux) which is attached, and with this it is easy to reproduce the
problem.
On Thu, 2009-12-17, Alan Spencer wrote:
> I've been asked to analyse a problem we have had with subversion and
> come to the conclusion there is a bug in at least the client.
>
>
> The scenario was someone committed a new directory that made a build
> fail and in order to free up the build this commit was reverse merges
> (merge -c -RRRR)
>
> The individual in question wanted their changes back and the opportunity
> to fix the problem. This was done by reverse merging the reverse merge.
>
> They then fixed the problems, which included renaming a file.
>
> They then committed these changes and updated and all looked OK.
>
> Updating on other working copy showed that both the original and renamed
> file existed, but the working copy used did not show this.
>
>
>
> I wanted to find out if this is user error or a bug and if it has been
> logged already.
This certainly looks like a bug. It sounds familiar, but I can't find it
in the issue tracker.
> And is there a way to achieve this without hitting this problem.
I'm not sure.
> Here is a log of my reproducing this:
[...]
> C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
> "Revert revert and renaming svn merge -c -16666 . svn move
> systemtest\audit\FirstName.txt systemtest\audit\SecondName.txt" .
> Adding experiment-1\systemtest\audit
> Adding experiment-1\systemtest\audit\SecondName.txt
> Committed revision 16667.
With a release candidate for 1.6.8, using the attached script, I get the
same result as you.
With a trunk build (r898816), using the attached script, I get a
different problem here: the commit sort of fails:
+ svn commit -m 'Revert revert and renaming svn merge -c -16666 . svn
move systemtest/audit/FirstName.txt systemtest/audit/SecondName.txt' .
Adding experiment-1/systemtest/audit
Deleting experiment-1/systemtest/audit/FirstName.txt
Adding experiment-1/systemtest/audit/SecondName.txt
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: The node 'FirstName.txt' was not found.
This is interesting, and it would be good to turn this script into a
test in the test suite so that we remember to fix the bug. Any
volunteers?
- Julian
>
> UPDATE ELSEWHERE
> ----------------------------------
>
> C:\dev\CO\trunk>svn up build\svn-experiments\experiment-1\
> A build\svn-experiments\experiment-1\systemtest\audit
> A build\svn-experiments\experiment-1\systemtest\audit\FirstName.txt
> A build\svn-experiments\experiment-1\systemtest\audit\SecondName.txt
> Updated to revision 16667.
Re: Probable bug with svn copy
Posted by Julian Foad <ju...@btopenworld.com>.
Hi Alan.
Thanks for this report, and sorry for the long time to respond.
I finally got around to converting your recipe into an executable script
(on Linux) which is attached, and with this it is easy to reproduce the
problem.
On Thu, 2009-12-17, Alan Spencer wrote:
> I've been asked to analyse a problem we have had with subversion and
> come to the conclusion there is a bug in at least the client.
>
>
> The scenario was someone committed a new directory that made a build
> fail and in order to free up the build this commit was reverse merges
> (merge -c -RRRR)
>
> The individual in question wanted their changes back and the opportunity
> to fix the problem. This was done by reverse merging the reverse merge.
>
> They then fixed the problems, which included renaming a file.
>
> They then committed these changes and updated and all looked OK.
>
> Updating on other working copy showed that both the original and renamed
> file existed, but the working copy used did not show this.
>
>
>
> I wanted to find out if this is user error or a bug and if it has been
> logged already.
This certainly looks like a bug. It sounds familiar, but I can't find it
in the issue tracker.
> And is there a way to achieve this without hitting this problem.
I'm not sure.
> Here is a log of my reproducing this:
[...]
> C:\dev\projects\build\build\svn-experiments\experiment-1>svn commit -m
> "Revert revert and renaming svn merge -c -16666 . svn move
> systemtest\audit\FirstName.txt systemtest\audit\SecondName.txt" .
> Adding experiment-1\systemtest\audit
> Adding experiment-1\systemtest\audit\SecondName.txt
> Committed revision 16667.
With a release candidate for 1.6.8, using the attached script, I get the
same result as you.
With a trunk build (r898816), using the attached script, I get a
different problem here: the commit sort of fails:
+ svn commit -m 'Revert revert and renaming svn merge -c -16666 . svn
move systemtest/audit/FirstName.txt systemtest/audit/SecondName.txt' .
Adding experiment-1/systemtest/audit
Deleting experiment-1/systemtest/audit/FirstName.txt
Adding experiment-1/systemtest/audit/SecondName.txt
svn: Commit succeeded, but other errors follow:
svn: Error bumping revisions post-commit (details follow):
svn: The node 'FirstName.txt' was not found.
This is interesting, and it would be good to turn this script into a
test in the test suite so that we remember to fix the bug. Any
volunteers?
- Julian
>
> UPDATE ELSEWHERE
> ----------------------------------
>
> C:\dev\CO\trunk>svn up build\svn-experiments\experiment-1\
> A build\svn-experiments\experiment-1\systemtest\audit
> A build\svn-experiments\experiment-1\systemtest\audit\FirstName.txt
> A build\svn-experiments\experiment-1\systemtest\audit\SecondName.txt
> Updated to revision 16667.