On Thu, Jun 07, 2018 at 04:30:49PM +0200, Stefan Sperling wrote:
> On Thu, Jun 07, 2018 at 02:19:59PM +0000, Rolf Campbell wrote:
> > I'm running a 2-URL merge, and svn is aborting when trying to resolve conflicts on a directory that's been added both locally and as part of the other branch being merged in. I cannot reproduce this using simple setups, I have not been able to isolate what exactly triggers this behaviour, but it is reproducable on my repository.
> >
> >
> > Here's the exact command that I run:
> >
> > svn merge ^/trunk ^/branches/feature/sempv2_vpn_mon_7 .
> >
> >
> > It produces many pages of add/modifies/deletes (the merge involve thousands of files), and then it starts interactive resolution of the conflicts.
> >
> >
> > Summary of conflicts:
> > Text conflicts: 40
> > Tree conflicts: 64
> >
> >
> > I start by choosing "mf" for the first 5 conflicts, and then when it get to the 6th conflict, it prints this:
> >
> > Merge conflicts in 'solcbr/common/commands/config/about/aboutCommands.py' marked as resolved.
> > Searching tree conflict details for 'solcbr/common/commands/config/about/user' in repository:
> > svn: E235000: In file 'subversion/libsvn_client/conflicts.c' line 2257: assertion failed (start_rev > end_rev)
> > Aborted (core dumped)
> >
> > For this path the "user" diroctory was added in both the "mon_7" branch and in the local branch.
> >
> > Is this something that I should be raising a bug for? I didn't see any bugs like this raised yet.
>
> Hi Rolf,
>
> Yes, please file an issue. I will try to look into this ASAP.
>
> If you could find a way for me to reproduce this problem
> locally that would be very much appreciated.
Hi Rolf,
I have not yet found out how I could reproduce this issue.
Are you able to repeat the problem, .e.g. by backdating your
working copy to an appropriate past revision and running the same
merge command again with appropriate peg-revisions appended to
the URL arguments?
(svn up -rX; svn merge ^/trunk_at_Y ^/branches/feature/sempv2_vpn_mon_7_at_Z . )
I understand this merge raises a lot of conflicts when you run it.
I only need information pertaining to the specific tree conflict which
raises the assertion failure. Could you provide more information about
how this tree conflict came about?
At a minimum, the output of 'svn info solcbr/common/commands/config/about/user'
while this directory is in a conflicted state would be useful to me.
The output of 'svn log -v' for the both of your two 'user' directories
on trunk and the branch might be useful as well. Specifically, I need to
understand at which revisions and paths these 2 directories were added,
relative to the revision in which the branch was copied from trunk, and
whether or not they differ in content.
The URL and revision of your merge target working copy would be good to
know, too ('svn info --show-item url' and 'svnversion' respectively).
Thanks,
Stefan
>
> Regards,
> Stefan
>
> >
> >
> > Backtrace from coredumpctl
> >
> > $ coredumpctl dump -o core.core
> > PID: 12115 (svn)
> > UID: 1000 (rolf)
> > GID: 1000 (rolf)
> > Signal: 6 (ABRT)
> > Timestamp: Thu 2018-06-07 10:15:53 EDT (2min 43s ago)
> > Command Line: svn merge -v ^/trunk ^/branches/feature/sempv2_vpn_mon_7 .
> > Executable: /usr/bin/svn
> > Control Group: /user.slice/user-1000.slice/user_at_1000.service/gnome-terminal-server.service
> > Unit: user_at_1000.service
> > User Unit: gnome-terminal-server.service
> > Slice: user-1000.slice
> > Owner UID: 1000 (rolf)
> > Boot ID: bb60a0b96550448fa5b28a1b529839c2
> > Machine ID: e2af878696fe4a589a249c535fc30788
> > Hostname: rolf-linux
> > Storage: /var/lib/systemd/coredump/core.svn.1000.bb60a0b96550448fa5b28a1b529839c2.12115.1528380953000000.lz4
> > Message: Process 12115 (svn) of user 1000 dumped core.
> >
> > Stack trace of thread 12115:
> > #0 0x00007fe79bdaaf2b raise (libc.so.6)
> > #1 0x00007fe79bd95561 abort (libc.so.6)
> > #2 0x00007fe79d9f5212 svn_error_abort_on_malfunction (libsvn_subr-1.so.0)
> > #3 0x00007fe7a01041cf find_revision_for_suspected_deletion (libsvn_client-1.so.0)
> > #4 0x00007fe7a01072de conflict_tree_get_details_incoming_add (libsvn_client-1.so.0)
> > #5 0x00007fe7a01034f9 svn_client_conflict_tree_get_details (libsvn_client-1.so.0)
> > #6 0x0000564e75aaa474 svn_cl__resolve_conflict (svn)
> > #7 0x0000564e75abb357 conflict_walker (svn)
> > #8 0x00007fe7a010f312 conflict_status_walker (libsvn_client-1.so.0)
> > #9 0x00007fe79fe6c8a8 send_status_structure (libsvn_wc-1.so.0)
> > #10 0x00007fe79fe6ded3 get_dir_status (libsvn_wc-1.so.0)
> > #11 0x00007fe79fe6f291 svn_wc__internal_walk_status (libsvn_wc-1.so.0)
> > #12 0x00007fe7a010f494 svn_client_conflict_walk (libsvn_client-1.so.0)
> > #13 0x0000564e75abb63c svn_cl__walk_conflicts (svn)
> > #14 0x0000564e75ab4a58 svn_cl__merge (svn)
> > #15 0x0000564e75ac004e sub_main (svn)
> > #16 0x0000564e75aa50e7 main (svn)
> > #17 0x00007fe79bd9718b __libc_start_main (libc.so.6)
> > #18 0x0000564e75aa516a _start (svn)
> >
> >
> >
> >
> > -Rolf
Received on 2018-06-19 17:16:01 CEST