You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2012/11/05 02:00:41 UTC
Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP
with VS2010 release build
Before I look into this further, I'd like to know if anyone else has seen
this or can reproduce this (or doesn't reproduce this with a similar
environment) ...
Tests 12 and 15 of mergeinfo-test.exe and test 4 of skel-test.exe hang on
my machine (i.e. they don't do anything useful anymore, but do fully
consume a cpu core until I kill them).
This is with trunk@1405553. All other tests, except the above three, run
successfully for me. I'm running Windows XP (32 bit).
I only see this happening with a release build (shared; haven't tried with
--disable-shared yet), when compiled with VS 2010.
I do *not* see this (i.e. tests complete normally) with:
- debug build made with VS 2010.
- release or debug builds made with VSExpress 2008.
Does anyone else have a release build on (any) Windows, made with VS 2010,
and can run these tests?
I'm using these dependencies:
Httpd 2.2.22
Apr 1.4.5
Apr-Util 1.4.1
Apr-Iconv 1.2.1
OpenSSL 1.0.1c
Serf 1.1.1
SQLite 3.7.14.1
ZLib 1.2.6
--
Johan
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Sun, Nov 11, 2012 at 7:14 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 11.11.2012 17:14, Stefan Fuhrmann wrote:
> > On Sun, Nov 11, 2012 at 4:48 PM, Daniel Shahaf <d.s@daniel.shahaf.name
> >wrote:
> >
> >> I don't know about conditionals in .vcproj files, but I assume it would
> >> at least be possible to drop an #error directive guarded by an #if
> >> directive on the compiler version.
> >>
> >
> http://code.google.com/p/notepad2-mod/issues/attachmentText?id=59&aid=590000000&name=compiler.patch&token=swu5D1m0KOU9RZ7KwjULuOxXKEI%3A1333263575004
> >
> > (scroll to the bottom)
> >
> > We could simply forbid release builds with VS2010 RTM
> > by #error out in e.g. svn_types.h
>
> svn_private_config.h, please. Weird checks like that go there, and it's
> already platform-specific enough that we won't pollute the Unix version..
>
Of course. I simply hadn't found that header because it's not in
svn/include.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Branko Čibej <br...@wandisco.com>.
On 11.11.2012 17:14, Stefan Fuhrmann wrote:
> On Sun, Nov 11, 2012 at 4:48 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
>> I don't know about conditionals in .vcproj files, but I assume it would
>> at least be possible to drop an #error directive guarded by an #if
>> directive on the compiler version.
>>
> http://code.google.com/p/notepad2-mod/issues/attachmentText?id=59&aid=590000000&name=compiler.patch&token=swu5D1m0KOU9RZ7KwjULuOxXKEI%3A1333263575004
>
> (scroll to the bottom)
>
> We could simply forbid release builds with VS2010 RTM
> by #error out in e.g. svn_types.h
svn_private_config.h, please. Weird checks like that go there, and it's
already platform-specific enough that we won't pollute the Unix version..
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Sun, Nov 11, 2012 at 4:48 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
> Johan Corveleyn wrote on Sun, Nov 11, 2012 at 09:46:00 +0100:
> > On Sat, Nov 10, 2012 at 11:45 PM, Daniel Shahaf <d....@daniel.shahaf.name>
> wrote:
> > > Johan Corveleyn wrote on Sat, Nov 10, 2012 at 15:35:21 +0100:
> > >> On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> > >>
> > >> [...]
> > >>
> > >> > Now, I have pinpointed the exact revision where the problems start
> for
> > >> > me. It's r1338286, where Bert enabled whole program optimizations
> for
> > >> > release builds, in the vcnet_vcxproj.ezt file.
> > >> >
> > >> > Maybe I'm running into some compiler bug (that has since been fixed
> in
> > >> > SP1), related to whole program optimization. I'll try installing SP1
> > >> > (but not right now, it's past 3 am now :-)) and see what happens.
> > >>
> > >> Finally got around to it, and indeed, the problem is solved when I use
> > >> VC2010 SP1. Test suite is running smoothly, and both
> > >> mergeinfo-test.exe and skel-test.exe have already succeeded.
> > >>
> > >> Now I finally have a good developer environment again, phew.
> > >>
> > >> Conclusion: don't use VC2010 without SP1.
> > >
> > > Can we make the build scripts trap that condition? (and error out, or
> > > disable whole-program optimisations)
> >
> > Good suggestion, but I have no idea really :-). I don't know enough
> > about the build scripts and project settings, and gen-make stuff etc
> > ...
> >
>
> I don't know about conditionals in .vcproj files, but I assume it would
> at least be possible to drop an #error directive guarded by an #if
> directive on the compiler version.
>
http://code.google.com/p/notepad2-mod/issues/attachmentText?id=59&aid=590000000&name=compiler.patch&token=swu5D1m0KOU9RZ7KwjULuOxXKEI%3A1333263575004
(scroll to the bottom)
We could simply forbid release builds with VS2010 RTM
by #error out in e.g. svn_types.h
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Sun, Nov 11, 2012 at 09:46:00 +0100:
> On Sat, Nov 10, 2012 at 11:45 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Johan Corveleyn wrote on Sat, Nov 10, 2012 at 15:35:21 +0100:
> >> On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> >>
> >> [...]
> >>
> >> > Now, I have pinpointed the exact revision where the problems start for
> >> > me. It's r1338286, where Bert enabled whole program optimizations for
> >> > release builds, in the vcnet_vcxproj.ezt file.
> >> >
> >> > Maybe I'm running into some compiler bug (that has since been fixed in
> >> > SP1), related to whole program optimization. I'll try installing SP1
> >> > (but not right now, it's past 3 am now :-)) and see what happens.
> >>
> >> Finally got around to it, and indeed, the problem is solved when I use
> >> VC2010 SP1. Test suite is running smoothly, and both
> >> mergeinfo-test.exe and skel-test.exe have already succeeded.
> >>
> >> Now I finally have a good developer environment again, phew.
> >>
> >> Conclusion: don't use VC2010 without SP1.
> >
> > Can we make the build scripts trap that condition? (and error out, or
> > disable whole-program optimisations)
>
> Good suggestion, but I have no idea really :-). I don't know enough
> about the build scripts and project settings, and gen-make stuff etc
> ...
>
I don't know about conditionals in .vcproj files, but I assume it would
at least be possible to drop an #error directive guarded by an #if
directive on the compiler version.
> But maybe someone else here has the expertise to pull this off?
>
> --
> Johan
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Nov 10, 2012 at 11:45 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Sat, Nov 10, 2012 at 15:35:21 +0100:
>> On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> [...]
>>
>> > Now, I have pinpointed the exact revision where the problems start for
>> > me. It's r1338286, where Bert enabled whole program optimizations for
>> > release builds, in the vcnet_vcxproj.ezt file.
>> >
>> > Maybe I'm running into some compiler bug (that has since been fixed in
>> > SP1), related to whole program optimization. I'll try installing SP1
>> > (but not right now, it's past 3 am now :-)) and see what happens.
>>
>> Finally got around to it, and indeed, the problem is solved when I use
>> VC2010 SP1. Test suite is running smoothly, and both
>> mergeinfo-test.exe and skel-test.exe have already succeeded.
>>
>> Now I finally have a good developer environment again, phew.
>>
>> Conclusion: don't use VC2010 without SP1.
>
> Can we make the build scripts trap that condition? (and error out, or
> disable whole-program optimisations)
Good suggestion, but I have no idea really :-). I don't know enough
about the build scripts and project settings, and gen-make stuff etc
...
But maybe someone else here has the expertise to pull this off?
--
Johan
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Sat, Nov 10, 2012 at 15:35:21 +0100:
> On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>
> [...]
>
> > Now, I have pinpointed the exact revision where the problems start for
> > me. It's r1338286, where Bert enabled whole program optimizations for
> > release builds, in the vcnet_vcxproj.ezt file.
> >
> > Maybe I'm running into some compiler bug (that has since been fixed in
> > SP1), related to whole program optimization. I'll try installing SP1
> > (but not right now, it's past 3 am now :-)) and see what happens.
>
> Finally got around to it, and indeed, the problem is solved when I use
> VC2010 SP1. Test suite is running smoothly, and both
> mergeinfo-test.exe and skel-test.exe have already succeeded.
>
> Now I finally have a good developer environment again, phew.
>
> Conclusion: don't use VC2010 without SP1.
Can we make the build scripts trap that condition? (and error out, or
disable whole-program optimisations)
> --
> Johan
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Nov 9, 2012 at 3:14 AM, Johan Corveleyn <jc...@gmail.com> wrote:
[...]
> Now, I have pinpointed the exact revision where the problems start for
> me. It's r1338286, where Bert enabled whole program optimizations for
> release builds, in the vcnet_vcxproj.ezt file.
>
> Maybe I'm running into some compiler bug (that has since been fixed in
> SP1), related to whole program optimization. I'll try installing SP1
> (but not right now, it's past 3 am now :-)) and see what happens.
Finally got around to it, and indeed, the problem is solved when I use
VC2010 SP1. Test suite is running smoothly, and both
mergeinfo-test.exe and skel-test.exe have already succeeded.
Now I finally have a good developer environment again, phew.
Conclusion: don't use VC2010 without SP1.
--
Johan
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Nov 8, 2012 at 7:30 AM, Stefan Fuhrmann
<st...@wandisco.com> wrote:
> On Tue, Nov 6, 2012 at 10:29 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> On Tue, Nov 6, 2012 at 10:53 AM, Stefan Fuhrmann
>> <st...@wandisco.com> wrote:
>> > On Mon, Nov 5, 2012 at 2:00 AM, Johan Corveleyn <jc...@gmail.com>
>> > wrote:
>> >>
>> >> Before I look into this further, I'd like to know if anyone else has
>> >> seen
>> >> this or can reproduce this (or doesn't reproduce this with a similar
>> >> environment) ...
>> >>
>> >> Tests 12 and 15 of mergeinfo-test.exe and test 4 of skel-test.exe hang
>> >> on
>> >> my machine (i.e. they don't do anything useful anymore, but do fully
>> >> consume
>> >> a cpu core until I kill them).
>> >>
>> >> This is with trunk@1405553. All other tests, except the above three,
>> >> run
>> >> successfully for me. I'm running Windows XP (32 bit).
>> >>
>> >> I only see this happening with a release build (shared; haven't tried
>> >> with
>> >> --disable-shared yet), when compiled with VS 2010.
>> >>
>> >> I do *not* see this (i.e. tests complete normally) with:
>> >> - debug build made with VS 2010.
>> >> - release or debug builds made with VSExpress 2008.
>> >>
>> >> Does anyone else have a release build on (any) Windows, made with VS
>> >> 2010,
>> >> and can run these tests?
>> >>
>> >> I'm using these dependencies:
>> >> Httpd 2.2.22
>> >> Apr 1.4.5
>> >> Apr-Util 1.4.1
>> >> Apr-Iconv 1.2.1
>> >> OpenSSL 1.0.1c
>> >> Serf 1.1.1
>> >> SQLite 3.7.14.1
>> >> ZLib 1.2.6
>> >
>> >
>> > They don't hang for me but I'm using a slightly older SQLite version.
>> > However, there has been a similar issue under Linux when running
>> > the tests in parallel. Python 2.7.2(?) has a sync. issue. Maybe, try
>> > updating your python installation.
>>
>> Thanks a lot for taking a look, Stefan.
>>
>> I have tried again with SQLite 3.7.12, but the result is the same. You
>> did use VC2010 for compilation, and tried with a release build, right?
>
>
> Yes, with SP1.
Aha, I don't have SP1 installed apparently (I remember I had some
problems with the installation of SP1, caused by general Windows
installation problems).
Now, I have pinpointed the exact revision where the problems start for
me. It's r1338286, where Bert enabled whole program optimizations for
release builds, in the vcnet_vcxproj.ezt file.
Maybe I'm running into some compiler bug (that has since been fixed in
SP1), related to whole program optimization. I'll try installing SP1
(but not right now, it's past 3 am now :-)) and see what happens.
Thanks for your help, Stefan.
--
Johan
Re: Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
> Julian Foad wrote:
>>>>>>>> SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
>>
>> I debugged this assertion failure and came up with this fix:
>>
>> [[[
>> Fix issue #4132 "merge of replaced source asserts", fixing merge_tests 125.
>>
>> * subversion/libsvn_client/merge.c
>> (find_gaps_in_merge_source_history): Fix an off-by-1 bug. Assert that the
>> function's result constitutes a valid non-empty range.
>>
>> Index: subversion/libsvn_client/merge.c
>> ===================================================================
>> --- subversion/libsvn_client/merge.c (revision 1414469)
>> +++ subversion/libsvn_client/merge.c (working copy)
>> @@ -4310,7 +4310,7 @@ find_gaps_in_merge_source_history(svn_re
>> /* Get SOURCE as mergeinfo. */
>> SVN_ERR(svn_client__get_history_as_mergeinfo(&implicit_src_mergeinfo, NULL,
>> primary_src,
>> - primary_src->rev, old_rev,
>> + primary_src->rev, old_rev + 1,
>> ra_session,
>> ctx, scratch_pool));
>>
>> @@ -4384,6 +4384,9 @@ find_gaps_in_merge_source_history(svn_re
>> SVN_ERR_ASSERT(*gap_start == MIN(source->loc1->rev, source->loc2->rev)
>> || (*gap_start == SVN_INVALID_REVNUM
>> && *gap_end == SVN_INVALID_REVNUM));
>> + SVN_ERR_ASSERT(*gap_end > *gap_start
>> + || (*gap_start == SVN_INVALID_REVNUM
>> + && *gap_end == SVN_INVALID_REVNUM));
>> return SVN_NO_ERROR;
>> }
>> ]]]
>>
>> Trouble is, this fix makes merge_tests.py 100 fail.
> merge_tests.py 100 demonstrates the problem with what you propose
[...]
[...]
[...]
> Anyway, I hope that helps explain what is happening here.
Thanks for the detailed walk-through, Paul.
What I have found so far (I spent a bit more time on it today) is that the error is *much* earlier than here, right at the start of the merge: normalize_merge_sources_internal() comes up with the result (2,9).
Adding some debugging as in the attached 'merge-t-125-1.patch':
$ svn merge -r9:2 .../A A_COPY --dry-run ...
DBG: merge.c:6566: oldest 2, youngest 9
DBG: merge.c:6592: Location segments:
DBG: merge.c:6597: 0: 2-2 'A'
DBG: merge.c:6597: 1: 3-6 '(null)'
DBG: merge.c:6597: 2: 7-9 'A'
DBG: merge.c:6701: Resulting merge_source_ts:
DBG: merge.c:6706: 0: 9 '.../repositories/merge_tests-100/A'
DBG: merge.c:6707: 2 '.../repositories/merge_tests-100/A'
So that's where I'm at.
- Julian
Re: Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Nov 27, 2012 at 6:53 PM, Julian Foad <ju...@btopenworld.com> wrote:
> Johan Corveleyn wrote:
>> On Sun, Nov 11, 2012 at 1:59 PM, Stefan Fuhrmann wrote:
>>> On Thu, Nov 8, 2012 at 6:04 PM, Julian Foad wrote:
>>>> Stefan Fuhrmann wrote:
>>>>> But I did run across an assertion in mergeinfo.c, :line 1174
>>>>>> during merge_tests.py 125:
>>>>>>>
>>>>>>> SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
>
> I debugged this assertion failure and came up with this fix:
>
> [[[
> Fix issue #4132 "merge of replaced source asserts", fixing merge_tests 125.
>
> * subversion/libsvn_client/merge.c
> (find_gaps_in_merge_source_history): Fix an off-by-1 bug. Assert that the
> function's result constitutes a valid non-empty range.
>
> Index: subversion/libsvn_client/merge.c
> ===================================================================
> --- subversion/libsvn_client/merge.c (revision 1414469)
> +++ subversion/libsvn_client/merge.c (working copy)
> @@ -4310,7 +4310,7 @@ find_gaps_in_merge_source_history(svn_re
> /* Get SOURCE as mergeinfo. */
> SVN_ERR(svn_client__get_history_as_mergeinfo(&implicit_src_mergeinfo, NULL,
> primary_src,
> - primary_src->rev, old_rev,
> + primary_src->rev, old_rev + 1,
> ra_session,
> ctx, scratch_pool));
>
> @@ -4384,6 +4384,9 @@ find_gaps_in_merge_source_history(svn_re
> SVN_ERR_ASSERT(*gap_start == MIN(source->loc1->rev, source->loc2->rev)
> || (*gap_start == SVN_INVALID_REVNUM
> && *gap_end == SVN_INVALID_REVNUM));
> + SVN_ERR_ASSERT(*gap_end > *gap_start
> + || (*gap_start == SVN_INVALID_REVNUM
> + && *gap_end == SVN_INVALID_REVNUM));
> return SVN_NO_ERROR;
> }
> ]]]
>
> Trouble is, this fix makes merge_tests.py 100 fail.
>
> I haven't yet investigated further.
Hi Julian,
(Let me say I'm thrilled this doesn't involve subtree mergeinfo :-)
merge_tests.py 100 demonstrates the problem with what you propose
above, but we can simplify things a bit since the underlying problem
doesn't have anything to do with reverse merges or a merge target with
uncommitted modifications (which are present in the test failure).
Let's start where merge_tests.py 100 fails, but first let's revert the
local changes. This leaves us with this WC based on this:
Rez 'A'
from 'A@2'
r1-------r2---r3---r4---r5----r6 r7--------r9---------->
Add 'A' edit edit edit edit Delete ^ | edit
psi rho beta omega 'A' | | gamma
\ | |
\___________copy____________/ |
|
|
|
r8---------------->
Copy 'A@7'
to 'A_COPY'
Let's try a cherry pick merge from A to A_COPY that spans the deletion
and resurrection of 'A':
Rez 'A'
from 'A@2'
r1-------r2---r3---r4---r5----r6 r7--------r9---------->
Add 'A' edit edit edit edit Delete ^ | edit |
psi rho beta omega 'A' | | gamma |
\ | | |
\___________copy____________/ | merge
| ^/A -r0:9
| |
| V
r8---------------->
Copy 'A@7'
to 'A_COPY'
Without your preceeding patch the merge does what I think is the right thing:
>svn merge -r0:9 ^^/A A_COPY
--- Merging r8 through r9 into 'A_COPY':
U A_COPY\D\gamma
--- Recording mergeinfo for merge of r8 through r9 into 'A_COPY':
U A_COPY
Ok, so what happens with your patch. First merge.c:merge_peg_locked()
calls normalize_merge_sources(), which notices the copy of 'A' at r7
and returns two merge_source_t to reflect this:
loc1
+ repos_root_url
"file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100"
+ repos_uuid "6156da17-bf42-b040-a6df-5ea1a8d7d9d7"
rev 1
+ url "file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100/A"
loc2
+ repos_root_url
"file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100"
+ repos_uuid "6156da17-bf42-b040-a6df-5ea1a8d7d9d7"
rev 2
+ url "file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100/A"
ancestral 1
loc1
+ repos_root_url
"file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100"
+ repos_uuid "6156da17-bf42-b040-a6df-5ea1a8d7d9d7"
rev 2
+ url "file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100/A"
loc2
+ repos_root_url
"file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100"
+ repos_uuid "6156da17-bf42-b040-a6df-5ea1a8d7d9d7"
rev 9
+ url "file:///C:/SVN/src-trunk/Debug/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-100/A"
ancestral 1
The merge of -r0:1 is obviously a no-op.
Picking up the second merge_source_t in merge.c:populate_remaining_ranges()
/* If, in the merge source's history, there was a copy from an older
revision, then SOURCE->loc2->url won't exist at some range M:N, where
SOURCE->loc1->rev < M < N < SOURCE->loc2->rev. The rules of 'MERGEINFO
MERGE SOURCE NORMALIZATION' allow this, but we must ignore these gaps
when calculating what ranges remain to be merged from SOURCE. If we
don't and try to merge any part of SOURCE->loc2->url@M:N we would
break the editor since no part of that actually exists. See
http://svn.haxx.se/dev/archive-2008-11/0618.shtml.
Find the gaps in the merge target's history, if any. Eventually
we will adjust CHILD->REMAINING_RANGES such that we don't describe
non-existent paths to the editor. */
SVN_ERR(find_gaps_in_merge_source_history(&gap_start, &gap_end,
source,
ra_session, merge_b->ctx,
iterpool));
You might want to take a look at the referenced thread,
http://svn.haxx.se/dev/archive-2008-11/0618.shtml, because the problem
I solved there is exactly the one your patch above recreates.
Once in find_gaps_in_merge_source_history(), we call
svn_client__get_history_as_mergeinfo(), which without your patch
returns this mergeinfo:
/A:2,7-9
But with your patch, which adds 1 to the RANGE_OLDEST arg of
svn_client__get_history_as_mergeinfo(), the following mergeinfo is
returned:
/A:7-9
This is a problem because we don't detect the copy and thus don't
detect the gap:
/* A gap in natural history can result from either a copy or
a rename. If from a copy then history as mergeinfo will look
something like this:
'/trunk:X,Y-Z'
If from a rename it will look like this:
'/trunk_old_name:X'
'/trunk_new_name:Y-Z'
In both cases the gap, if it exists, is M-N, where M = X + 1 and
N = Y - 1.
Note that per the rules of 'MERGEINFO MERGE SOURCE NORMALIZATION' we
should never have multiple gaps, e.g. if we see anything like the
following then something is quite wrong:
'/trunk_old_name:A,B-C'
'/trunk_new_name:D-E'
*/
### rangelist->nelts == 1 with your patch
### so we never enter this block
### VVV
if (rangelist->nelts > 1) /* Copy */
{
/* As mentioned above, multiple gaps *shouldn't* be possible. */
SVN_ERR_ASSERT(apr_hash_count(implicit_src_mergeinfo) == 1);
*gap_start = MIN(source->loc1->rev, source->loc2->rev);
*gap_end = (APR_ARRAY_IDX(rangelist,
rangelist->nelts - 1,
svn_merge_range_t *))->start;
}
Back in merge.c:populate_remaining_ranges() we never know about the
gap so we don't stash it in the merge cmd baton:
/* Stash any gap in the merge command baton, we'll need it later when
recording mergeinfo describing this merge. */
if (SVN_IS_VALID_REVNUM(gap_start) && SVN_IS_VALID_REVNUM(gap_end))
merge_b->implicit_src_gap = svn_rangelist__initialize(gap_start, gap_end,
TRUE, result_pool);
Then later in populate_remaining_ranges(), we don't adjust our
remaining ranges to merge:
/* Deal with any gap in SOURCE's natural history.
If the gap is a proper subset of CHILD->REMAINING_RANGES then we can
safely ignore it since we won't describe this path/rev pair.
If the gap exactly matches or is a superset of a range in
CHILD->REMAINING_RANGES then we must remove that range so we don't
attempt to describe non-existent paths via the reporter, this will
break the editor and our merge.
If the gap adjoins or overlaps a range in CHILD->REMAINING_RANGES
then we must *add* the gap so we span the missing revisions. */
if (child->remaining_ranges->nelts
&& merge_b->implicit_src_gap)
...
Ok, I'm rambling, so let me move to the summing up part :-)
The above leaves the merge code thinking that the requested merge is:
/A:2-9 (The naive merge request)
Less what's already been merged per the target's implicit mergeinfo:
/A:2,7
/A_COPY:8-9
Less what's already been merged per the target's explict mergefino:
"" (None in this case)
Which leaves:
/A:3-6,8-9
To be merged. We should have removed the non-existent gap /A:3-6, but
as we saw above we didn't. Skipping ahead to
drive_merge_report_editor(), we try to merge this gap, calling
svn_client__get_diff_editor(revision=2) and then
svn_ra_do_diff3(revision=6). Since A@6 doesn't exist, the editor
breaks:
>svn merge -r0:9 ^^/A A_COPY
..\..\..\subversion\svn\util.c:913: (apr_err=160005)
..\..\..\subversion\libsvn_client\merge.c:11074: (apr_err=160005)
..\..\..\subversion\libsvn_client\merge.c:11040: (apr_err=160005)
..\..\..\subversion\libsvn_client\merge.c:9219: (apr_err=160005)
..\..\..\subversion\libsvn_client\merge.c:8925: (apr_err=160005)
..\..\..\subversion\libsvn_client\merge.c:8787: (apr_err=160005)
..\..\..\subversion\libsvn_client\merge.c:5243: (apr_err=160005)
..\..\..\subversion\libsvn_repos\reporter.c:1543: (apr_err=160005)
..\..\..\subversion\libsvn_repos\reporter.c:1458: (apr_err=160005)
..\..\..\subversion\libsvn_repos\reporter.c:1370: (apr_err=160005)
svn: E160005: Target path '/A' does not exist
Anyway, I hope that helps explain what is happening here.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125
Posted by Julian Foad <ju...@btopenworld.com>.
Johan Corveleyn wrote:
> On Sun, Nov 11, 2012 at 1:59 PM, Stefan Fuhrmann wrote:
>> On Thu, Nov 8, 2012 at 6:04 PM, Julian Foad wrote:
>>> Stefan Fuhrmann wrote:
>>>> But I did run across an assertion in mergeinfo.c, :line 1174
>>>>> during merge_tests.py 125:
>>>>>>
>>>>>> SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
I debugged this assertion failure and came up with this fix:
[[[
Fix issue #4132 "merge of replaced source asserts", fixing merge_tests 125.
* subversion/libsvn_client/merge.c
(find_gaps_in_merge_source_history): Fix an off-by-1 bug. Assert that the
function's result constitutes a valid non-empty range.
Index: subversion/libsvn_client/merge.c
===================================================================
--- subversion/libsvn_client/merge.c (revision 1414469)
+++ subversion/libsvn_client/merge.c (working copy)
@@ -4310,7 +4310,7 @@ find_gaps_in_merge_source_history(svn_re
/* Get SOURCE as mergeinfo. */
SVN_ERR(svn_client__get_history_as_mergeinfo(&implicit_src_mergeinfo, NULL,
primary_src,
- primary_src->rev, old_rev,
+ primary_src->rev, old_rev + 1,
ra_session,
ctx, scratch_pool));
@@ -4384,6 +4384,9 @@ find_gaps_in_merge_source_history(svn_re
SVN_ERR_ASSERT(*gap_start == MIN(source->loc1->rev, source->loc2->rev)
|| (*gap_start == SVN_INVALID_REVNUM
&& *gap_end == SVN_INVALID_REVNUM));
+ SVN_ERR_ASSERT(*gap_end > *gap_start
+ || (*gap_start == SVN_INVALID_REVNUM
+ && *gap_end == SVN_INVALID_REVNUM));
return SVN_NO_ERROR;
}
]]]
Trouble is, this fix makes merge_tests.py 100 fail.
I haven't yet investigated further.
In doing that I studied svn_client__get_history_as_mergeinfo() and what it's built on, and came up with a unit test improvement (r1414414) and the following doc improvements:
[[[
Index: subversion/include/svn_ra.h
===================================================================
/* [...]
* @a peg_revision may be @c SVN_INVALID_REVNUM to indicate "the HEAD
* revision", and must evaluate to be at least as young as @a start_rev.
*
+ * The sequence of segments passed to @a receiver will describe adjacent,
+ * non-overlapping ranges of revisions. The highest reported revision
+ * (@c range_end of the first segment) will always be @a start_rev, and the
+ * lowest reported revision (@c range_start of the last segment) will be
+ * @a end_rev or the origin of the object, whichever is higher.
+ *
* [...] */
svn_error_t *
svn_ra_get_location_segments(svn_ra_session_t *session, [...]);
Index: subversion/include/svn_types.h
===================================================================
/**
- * A representation of a segment of a object's version history with an
+ * A representation of a segment of an object's version history with an
* emphasis on the object's location in the repository as of various
* revisions.
* [...] */
typedef struct svn_location_segment_t
{
/** The beginning (oldest) and ending (youngest) revisions for this
- segment. */
+ segment, both inclusive. */
svn_revnum_t range_start;
svn_revnum_t range_end;
Index: subversion/libsvn_client/mergeinfo.h
===================================================================
/* Set *MERGEINFO_P to a mergeinfo constructed solely from the
natural history of PATHREV.
- If RANGE_YOUNGEST and RANGE_OLDEST are valid, use them to bound the
- revision ranges of returned mergeinfo. They are governed by the same
- rules as the PEG_REVISION, START_REV, and END_REV parameters of
+ If RANGE_YOUNGEST and RANGE_OLDEST are valid, use them as inclusive
+ bounds on the revision ranges of returned mergeinfo. PATHREV->rev,
+ RANGE_YOUNGEST and RANGE_OLDEST are governed by the same rules as the
+ PEG_REVISION, START_REV, and END_REV parameters (respectively) of
svn_ra_get_location_segments().
[...] */
svn_error_t *
svn_client__get_history_as_mergeinfo(svn_mergeinfo_t *mergeinfo_p, [...]);
]]]
- Julian
Re: Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125 [was:
Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with
VS2010 release build]
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Nov 11, 2012 at 1:59 PM, Stefan Fuhrmann
<st...@wandisco.com> wrote:
>
>
> On Thu, Nov 8, 2012 at 6:04 PM, Julian Foad <ju...@btopenworld.com>
> wrote:
>>
>> Stefan Fuhrmann wrote:
>>
>> > But I did run across an assertion in mergeinfo.c, :line 1174
>> >
>> >> during merge_tests.py 125:
>> >>>
>> >>> SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
>> >
>> > The weird thing about the assertion is, that the tests
>> > will continue just fine afterwards and no error was
>> > reported. I suspect some compiler optimization issue
>> > or some missing initialization.
>>
>>
>> I see this too. The test is marked XFAIL.
>
>
> OK, that explains why it simply carries on afterwards.
> It has been the first test that popped up the "your app
> terminated unexpectedly" window. And that is not
> nice behavior for an automated test suite.
Yeah, that reminds me that I had the same problem, already for a long
time (I don't notice it anymore). See this thread:
http://thread.gmane.org/gmane.comp.version-control.subversion.devel/125147
It's only when you run the test suite with a release build. With a
debug build, you won't get the annoying popup. But with a release
build on Windows, it's quite annoying that you can't run it
unattended...
--
Johan
Re: Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125 [was:
Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with
VS2010 release build]
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Nov 8, 2012 at 6:04 PM, Julian Foad <ju...@btopenworld.com>wrote:
> Stefan Fuhrmann wrote:
>
> > But I did run across an assertion in mergeinfo.c, :line 1174
> >
> >> during merge_tests.py 125:
> >>>
> >>> SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
> >
> > The weird thing about the assertion is, that the tests
> > will continue just fine afterwards and no error was
> > reported. I suspect some compiler optimization issue
> > or some missing initialization.
>
>
> I see this too. The test is marked XFAIL.
>
OK, that explains why it simply carries on afterwards.
It has been the first test that popped up the "your app
terminated unexpectedly" window. And that is not
nice behavior for an automated test suite.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Assert IS_VALID_FORWARD_RANGE fails in merge_tests 125 [was: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on WinXP with VS2010 release build]
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Fuhrmann wrote:
> But I did run across an assertion in mergeinfo.c, :line 1174
>
>> during merge_tests.py 125:
>>>
>>> SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
>
> The weird thing about the assertion is, that the tests
> will continue just fine afterwards and no error was
> reported. I suspect some compiler optimization issue
> or some missing initialization.
I see this too. The test is marked XFAIL.
- Julian
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Nov 6, 2012 at 10:29 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Nov 6, 2012 at 10:53 AM, Stefan Fuhrmann
> <st...@wandisco.com> wrote:
> > On Mon, Nov 5, 2012 at 2:00 AM, Johan Corveleyn <jc...@gmail.com>
> wrote:
> >>
> >> Before I look into this further, I'd like to know if anyone else has
> seen
> >> this or can reproduce this (or doesn't reproduce this with a similar
> >> environment) ...
> >>
> >> Tests 12 and 15 of mergeinfo-test.exe and test 4 of skel-test.exe hang
> on
> >> my machine (i.e. they don't do anything useful anymore, but do fully
> consume
> >> a cpu core until I kill them).
> >>
> >> This is with trunk@1405553. All other tests, except the above three,
> run
> >> successfully for me. I'm running Windows XP (32 bit).
> >>
> >> I only see this happening with a release build (shared; haven't tried
> with
> >> --disable-shared yet), when compiled with VS 2010.
> >>
> >> I do *not* see this (i.e. tests complete normally) with:
> >> - debug build made with VS 2010.
> >> - release or debug builds made with VSExpress 2008.
> >>
> >> Does anyone else have a release build on (any) Windows, made with VS
> 2010,
> >> and can run these tests?
> >>
> >> I'm using these dependencies:
> >> Httpd 2.2.22
> >> Apr 1.4.5
> >> Apr-Util 1.4.1
> >> Apr-Iconv 1.2.1
> >> OpenSSL 1.0.1c
> >> Serf 1.1.1
> >> SQLite 3.7.14.1
> >> ZLib 1.2.6
> >
> >
> > They don't hang for me but I'm using a slightly older SQLite version.
> > However, there has been a similar issue under Linux when running
> > the tests in parallel. Python 2.7.2(?) has a sync. issue. Maybe, try
> > updating your python installation.
>
> Thanks a lot for taking a look, Stefan.
>
> I have tried again with SQLite 3.7.12, but the result is the same. You
> did use VC2010 for compilation, and tried with a release build, right?
>
Yes, with SP1.
> Which SQLite version did you use actually?
>
3.7.12. Everything 32 bits under Vista 32 bits.
> I'm not running the test suite in parallel, and I'm also seeing it
> when I run only that single test:
>
> python win-tests.py -c --release -t mergeinfo-test.exe#12 R:\test
>
That works on my machine.
> Besides I'm using Python 2.7.3, which IIUC is the latest production
> release of the 2.x family.
> Thanks for the suggestion though.
>
> I guess the next step for me is to try and reproduce this when running
> from within the IDE ... or try bisecting.
>
You can always attach to the hanging process and
see where it got stuck.
> > But I did run across an assertion in mergeinfo.c, :line 1174
> > during merge_tests.py 125:
> >
> > SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
> >
>
> Hm, I haven't seen that one yet (I'm looking specifically at
> merginfo-test.exe, not merge_tests.py, but I did run the rest of the
> test suite successfully, so this has definitely passed for me --
> though as I said, I don't run them in parallel).
>
I'm not running the test suite in parallel on Windows.
When I did under Linux, python 2.7.2 would "just hang"
at random after finishing a test.
The weird thing about the assertion is, that the tests
will continue just fine afterwards and no error was
reported. I suspect some compiler optimization issue
or some missing initialization.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Nov 6, 2012 at 10:53 AM, Stefan Fuhrmann
<st...@wandisco.com> wrote:
> On Mon, Nov 5, 2012 at 2:00 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> Before I look into this further, I'd like to know if anyone else has seen
>> this or can reproduce this (or doesn't reproduce this with a similar
>> environment) ...
>>
>> Tests 12 and 15 of mergeinfo-test.exe and test 4 of skel-test.exe hang on
>> my machine (i.e. they don't do anything useful anymore, but do fully consume
>> a cpu core until I kill them).
>>
>> This is with trunk@1405553. All other tests, except the above three, run
>> successfully for me. I'm running Windows XP (32 bit).
>>
>> I only see this happening with a release build (shared; haven't tried with
>> --disable-shared yet), when compiled with VS 2010.
>>
>> I do *not* see this (i.e. tests complete normally) with:
>> - debug build made with VS 2010.
>> - release or debug builds made with VSExpress 2008.
>>
>> Does anyone else have a release build on (any) Windows, made with VS 2010,
>> and can run these tests?
>>
>> I'm using these dependencies:
>> Httpd 2.2.22
>> Apr 1.4.5
>> Apr-Util 1.4.1
>> Apr-Iconv 1.2.1
>> OpenSSL 1.0.1c
>> Serf 1.1.1
>> SQLite 3.7.14.1
>> ZLib 1.2.6
>
>
> They don't hang for me but I'm using a slightly older SQLite version.
> However, there has been a similar issue under Linux when running
> the tests in parallel. Python 2.7.2(?) has a sync. issue. Maybe, try
> updating your python installation.
Thanks a lot for taking a look, Stefan.
I have tried again with SQLite 3.7.12, but the result is the same. You
did use VC2010 for compilation, and tried with a release build, right?
Which SQLite version did you use actually?
I'm not running the test suite in parallel, and I'm also seeing it
when I run only that single test:
python win-tests.py -c --release -t mergeinfo-test.exe#12 R:\test
Besides I'm using Python 2.7.3, which IIUC is the latest production
release of the 2.x family.
Thanks for the suggestion though.
I guess the next step for me is to try and reproduce this when running
from within the IDE ... or try bisecting.
> But I did run across an assertion in mergeinfo.c, :line 1174
> during merge_tests.py 125:
>
> SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
>
Hm, I haven't seen that one yet (I'm looking specifically at
merginfo-test.exe, not merge_tests.py, but I did run the rest of the
test suite successfully, so this has definitely passed for me --
though as I said, I don't run them in parallel).
--
Johan
Re: Hanging tests mergeinfo-test.exe 12, 15 and skel-test.exe 4 on
WinXP with VS2010 release build
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, Nov 5, 2012 at 2:00 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> Before I look into this further, I'd like to know if anyone else has seen
> this or can reproduce this (or doesn't reproduce this with a similar
> environment) ...
>
> Tests 12 and 15 of mergeinfo-test.exe and test 4 of skel-test.exe hang on
> my machine (i.e. they don't do anything useful anymore, but do fully
> consume a cpu core until I kill them).
>
> This is with trunk@1405553. All other tests, except the above three, run
> successfully for me. I'm running Windows XP (32 bit).
>
> I only see this happening with a release build (shared; haven't tried with
> --disable-shared yet), when compiled with VS 2010.
>
> I do *not* see this (i.e. tests complete normally) with:
> - debug build made with VS 2010.
> - release or debug builds made with VSExpress 2008.
>
> Does anyone else have a release build on (any) Windows, made with VS 2010,
> and can run these tests?
>
> I'm using these dependencies:
> Httpd 2.2.22
> Apr 1.4.5
> Apr-Util 1.4.1
> Apr-Iconv 1.2.1
> OpenSSL 1.0.1c
> Serf 1.1.1
> SQLite 3.7.14.1
> ZLib 1.2.6
>
They don't hang for me but I'm using a slightly older SQLite version.
However, there has been a similar issue under Linux when running
the tests in parallel. Python 2.7.2(?) has a sync. issue. Maybe, try
updating your python installation.
But I did run across an assertion in mergeinfo.c, :line 1174
during merge_tests.py 125:
SVN_ERR_ASSERT_NO_RETURN(IS_VALID_FORWARD_RANGE(first));
Stack trace below.
-- Stefan^2.
> libsvn_subr-1.dll!range_contains(const svn_merge_range_t *
first=0x01df18f8, const svn_merge_range_t * second=0x0016f488, int
consider_inheritance=0) Line 1174 + 0x29 bytes C
first 0x01df18f8 {start=4 end=4 inheritable=1 } const
svn_merge_range_t *
second 0x0016f488 {start=4 end=5 inheritable=1 } const
svn_merge_range_t *
consider_inheritance 0 int
libsvn_subr-1.dll!rangelist_intersect_or_remove(apr_array_header_t * *
output=0x0016f508, const apr_array_header_t * rangelist1=0x01df18d8, const
apr_array_header_t * rangelist2=0x00000000, int do_remove=1, int
consider_inheritance=0, apr_pool_t * pool=0x01e691f8) Line 1332 + 0xc
bytes C
output 0x0016f508 apr_array_header_t * *
rangelist1 0x01df18d8 {pool=0x01df1138 elt_size=4 nelts=1
...} const apr_array_header_t *
rangelist2 0x00000000 {pool=??? elt_size=??? nelts=??? ...}
const apr_array_header_t *
do_remove 1 int
consider_inheritance 0 int
pool 0x01e691f8 apr_pool_t *
i2 0 int
working_elt2 {start=4 end=5 inheritable=1 } svn_merge_range_t
i1 0 int
lasti2 0 int
tmp_range {start=1860994357 end=0 inheritable=0 }
svn_merge_range_t
tmp_range {start=1504396 end=31887864 inheritable=1766373840
} svn_merge_range_t
tmp_range {start=1504832 end=1504400 inheritable=1766373899 }
svn_merge_range_t
libsvn_subr-1.dll!svn_rangelist_remove(apr_array_header_t * *
output=0x0016f508, const apr_array_header_t * eraser=0x01df18d8, const
apr_array_header_t * whiteboard=0x01e69240, int consider_inheritance=0,
apr_pool_t * pool=0x01e691f8) Line 1492 + 0x1a bytes C
libsvn_client-1.dll!record_mergeinfo_for_dir_merge(apr_hash_t *
result_catalog=0x00000000, const svn_merge_range_t *
merged_range=0x0016f590, const char * mergeinfo_fspath=0x01df23f8,
svn_depth_t depth=svn_depth_infinity, int
squelch_mergeinfo_notifications=0, notification_receiver_baton_t *
notify_b=0x0016f610, merge_cmd_baton_t * merge_b=0x0016f640, apr_pool_t *
scratch_pool=0x00000000) Line 7927 + 0x15 bytes C
libsvn_client-1.dll!do_mergeinfo_aware_dir_merge(apr_hash_t *
result_catalog=0x00000000, const merge_source_t * source=0x01da8b80, const
char * target_abspath=0x0016f5c4, svn_depth_t depth=svn_depth_empty, int
squelch_mergeinfo_notifications=0, int abort_on_conflicts=0,
notification_receiver_baton_t * notify_b=0x0016f610, merge_cmd_baton_t *
merge_b=0x0016f640, apr_pool_t * scratch_pool=0x01df1138) Line 8859 + 0x1d
bytes C
libsvn_client-1.dll!do_directory_merge(apr_hash_t *
result_catalog=0x00000000, const merge_source_t * source=0x01da8b80, const
char * target_abspath=0x01da80d8, svn_depth_t depth=svn_depth_infinity, int
squelch_mergeinfo_notifications=0, int abort_on_conflicts=0,
notification_receiver_baton_t * notify_b=0x0016f610, merge_cmd_baton_t *
merge_b=0x0016f640, apr_pool_t * scratch_pool=0x01df1138) Line 8918 + 0x1a
bytes C
libsvn_client-1.dll!do_merge(apr_hash_t * *
modified_subtrees=0x00000000, apr_hash_t * result_catalog=0x00000000, const
apr_array_header_t * merge_sources=0x01da8630, const merge_target_t *
target=0x01da80c0, svn_ra_session_t * src_session=0x01daa150, int
sources_related=1, int same_repos=1, int ignore_ancestry=0, int force=0,
int dry_run=0, int record_only=0, apr_hash_t *
record_only_paths=0x00000000, int reintegrate_merge=0, int
squelch_mergeinfo_notifications=0, svn_depth_t depth=svn_depth_infinity,
const apr_array_header_t * merge_options=0x00000000, int *
use_sleep=0x0016f714, svn_client_ctx_t * ctx=0x00cdee18, apr_pool_t *
result_pool=0x01da8080, apr_pool_t * scratch_pool=0x01da8080) Line 9212 +
0x29 bytes C
libsvn_client-1.dll!merge_peg_locked(const char *
source_path_or_url=0x00000000, const svn_opt_revision_t *
source_peg_revision=0x0016f7e0, const apr_array_header_t *
ranges_to_merge=0x00cddf98, const char * target_abspath=0x01d8ec30,
svn_depth_t depth=-2, int ignore_ancestry=0, int force=0, int
record_only=0, int dry_run=0, int allow_mixed_rev=0, const
apr_array_header_t * merge_options=0x00000000, svn_client_ctx_t *
ctx=0x00cdee18, apr_pool_t * scratch_pool=0x00cdde10) Line 11025 + 0x40
bytes C
libsvn_client-1.dll!svn_client_merge_peg4(const char *
source_path_or_url=0x01d8ea38, const apr_array_header_t *
ranges_to_merge=0x01d8ec30, const svn_opt_revision_t *
source_peg_revision=0x0016f7e0, const char * target_wcpath=0x00cdf960,
svn_depth_t depth=-2, int ignore_ancestry=0, int force=0, int
record_only=0, int dry_run=0, int allow_mixed_rev=0, const
apr_array_header_t * merge_options=0x00000000, svn_client_ctx_t *
ctx=0x00cdee18, apr_pool_t * pool=0x00cdde10) Line 11067 + 0x4e bytes C
svn.exe!svn_cl__merge(apr_getopt_t * os=0x00cddfb8, void *
baton=0x0016f8c0, apr_pool_t * pool=0x00cdde10) Line 497 + 0x49 bytes C
svn.exe!sub_main(int argc=0, const char * * argv=0x00000000,
apr_pool_t * pool=) Line 2721 + 0x18 bytes C
svn.exe!main(int argc=13, const char * * argv=0x01bf1be8) Line 2790 +
0xe bytes C
svn.exe!__tmainCRTStartup() Line 555 + 0x17 bytes C
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*