On Wed, Nov 26, 2008 at 2:17 AM, Michael Susser <hdmlist_at_googlemail.com> wrote:
> Hello community,
>
> i think i have found a small bug regarding dry-run-merge in svn versions >
> 1.5.3. The error message i get is the following:
>
> svn merge --accept postpone --dry-run -c43053
> http://vmprjsrv02/svn/APPL/SCU/SPC/branches/b09A D:/wc/p09A/Tp/Spc
> -- Zusammenführen von r43053 in
> »D:\wc\p09A\Tp\Spc\Tp\TestCenter\Src\CoatingUnitTest«:
> U D:\wc\p09A\Tp\Spc\Tp\TestCenter\Src\CoatingUnitTest\Id_18519.tsd
> U D:\wc\p09A\Tp\Spc\Tp\TestCenter\Src\CoatingUnitTest\Id_18520.tsd
> U D:\wc\p09A\Tp\Spc\Tp\TestCenter\Src\CoatingUnitTest\Id_18521.tsd
> U D:\wc\p09A\Tp\Spc\Tp\TestCenter\Src\CoatingUnitTest\Id_18525.tsd
> G D:\wc\p09A\Tp\Spc\Tp\TestCenter\Src\CoatingUnitTest
> d:\svnserver\src-tags-1.5.4\subversion\libsvn_wc\lock.c:1433:
> (apr_err=155005)
> svn: Keine Schreibsperre in
> »D:\wc\p09A\Tp\Spc\Tp\TestCenter\Src\CoatingUnitTest«
>
> ("Keine Schreibsperre" means "No write-lock")
>
> I tried to create a recipe to reproduce this message but did not succeed.
> Maybe the history of my working copy is too complex. The bug does not occur
> in svn versions 1.5.0-1.5.3.
>
> Then i debugged a little bit and found the reason for the error in
> libsvn_client/merge.c in the new function
> "process_children_with_new_mergeinfo" (which was introduced in 1.5.4). Here
> is a patch that worked for me, but i do not know what side effects it has:
>
> Index: merge.c
> ===================================================================
> --- merge.c (revision 34373)
> +++ merge.c (working copy)
> @@ -5144,9 +5144,12 @@
> SVN_ERR(svn_mergeinfo_merge(path_explicit_mergeinfo,
> path_inherited_mergeinfo,
> iterpool));
> -
> SVN_ERR(svn_client__record_wc_mergeinfo(path_with_new_mergeinfo,
> -
> path_explicit_mergeinfo,
> - adm_access,
> iterpool));
> + if (!merge_b->dry_run)
> + {
> +
> SVN_ERR(svn_client__record_wc_mergeinfo(path_with_new_mergeinfo,
> +
> path_explicit_mergeinfo,
> + adm_access,
> iterpool));
> + }
> }
>
> /* If the path is not in NOTIFY_B->CHILDREN_WITH_MERGEINFO
>
> Can anyone confirm that this is a bug or not, please?
Hi Michael,
It is indeed a bug and your patch is basically the right approach.
But we can go a bit further and not bother creating/populating the
paths_with_new_mergeinfo hash during a dry-run and also make the
entirety of process_children_with_new_mergeinfo a no-op for dry-runs.
That should solve your bug and eliminate some unnecessary work during
dry-runs.
Committed this change in r34432 and will nominate it for backport to 1.5.x.
Paul
Received on 2008-11-26 18:04:53 CET