tree conflict in merge after deleting and re-adding files
Hi All, TortoiseSVN 1.6.16, Build 21511 - 64 Bit , 2011/06/01 19:00:35 Subversion 1.6.17, apr 1.3.12 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0d 8 Feb 2011 zlib 1.2.5 We have a problem. We have a trunk and a branch, and wanted to merge changes from branch to trunk. Due to some heavier file-conflicts I'we deleted foo.txt in trunk in SVN, copied it from branch and added again. Now I now it was a mistake. Now if we try to make merge, we always get tree conflict on foo.txt - its contents are already identical in trunk and branch. I know that the discontinuity in foo.txt for a range of revisions, so the lack of ancestry causes that. foo.txt was already deleted and re-added in branch by other developer. We have already tried a range of solutions found on the web, but no success. Is there a way to tell SVN to forget this tree conflict thing for ever? thank you in advance. Best regards: Balázs
RE: tree conflict in merge after deleting and re-adding files
Hi All, TortoiseSVN 1.6.16, Build 21511 - 64 Bit , 2011/06/01 19:00:35 Subversion 1.6.17, apr 1.3.12 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0d 8 Feb 2011 zlib 1.2.5 We have a problem. We have a trunk and a branch, and wanted to merge changes from branch to trunk. Due to some heavier file-conflicts I'we deleted foo.txt in trunk in SVN, copied it from branch and added again. Now I now it was a mistake. Now if we try to make merge, we always get tree conflict on foo.txt - its contents are already identical in trunk and branch. I know that the discontinuity in foo.txt for a range of revisions, so the lack of ancestry causes that. foo.txt was already deleted and re-added in branch by other developer. We have already tried a range of solutions found on the web, but no success. Is there a way to tell SVN to forget this tree conflict thing for ever? thank you in advance. Best regards: Balázs If you do a merge, and resolve the tree conflict, and then commit the merge... subsequent merges will no longer try to merge in the delete change and you shouldn't see further issues. If you keep seeing the same conflict, it sounds like you aren't committing the merge-info that is set on the project root. (you should always merge from the project root). BOb
Re: tree conflict in merge after deleting and re-adding files
On Wed, Oct 09, 2013 at 06:50:32PM +0200, Balázs Bámer wrote: Hi All, TortoiseSVN 1.6.16, Build 21511 - 64 Bit , 2011/06/01 19:00:35 Subversion 1.6.17, apr 1.3.12 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0d 8 Feb 2011 zlib 1.2.5 We have a problem. We have a trunk and a branch, and wanted to merge changes from branch to trunk. Due to some heavier file-conflicts I'we deleted foo.txt in trunk in SVN, copied it from branch and added again. Now I now it was a mistake. Now if we try to make merge, we always get tree conflict on foo.txt - its contents are already identical in trunk and branch. I know that the discontinuity in foo.txt for a range of revisions, so the lack of ancestry causes that. foo.txt was already deleted and re-added in branch by other developer. We have already tried a range of solutions found on the web, but no success. Is there a way to tell SVN to forget this tree conflict thing for ever? thank you in advance. Best regards: Balázs You've created a new line of history for the name foo.txt. Delete the new foo.txt, and copy the old foo.txt (from before when you first deleted it) to the same path. Then change foo.txt contents to match the contents of the new foo.txt (this can be done via 'svn merge' but also with an editor). Commit. After that, now you'll need to resolve a tree conflict once more when you merge the addition of the old-new foo.txt to the branch. Accept the incoming replacement (there won't be a menu item to do this, you'll need to copy the file from the other branch into the working copy yourself and mark the conflict resolved with svn resolve --accept=working). Then edit the replaced file so it has the proepr contents for the branch. Not easy, and certainly something where Subversion could do a lot better with helping the user jump through hoops. But it's not impossible either. For the future, keep in mind that Subversion applies tree changes first, and content changes second. Always. If you are replacing a file, rather than replacing its contents, Subversion takes your word for it and does that. Note that some cases where a replacement happened accidentally (such as svn move A B; svn move B A;) have been fixed in Subversion 1.8. You should strongly consider an upgrade from 1.6!
Re: svn 1.8 client segmentation fault when checking out Subversion trunk repository
On Tue, Oct 8, 2013 at 8:35 PM, Martin Zibricky mzibr.pub...@gmail.comwrote: Hi everyone, I'm trying to compile svn 1.8.3 with lsbcc (Linux Standard Base). Everything compiles fine but when trying to checkout Subversion trunk ( http://svn.apache.org/repos/asf/subversion/trunk/ ) the svn client crashes with the segmentation fault in the middle of checkout and I get broken working copy. This is the GDB output with enabled debugging output --enable-maintainer-mode option: --- $ gdb env/local/tools/svn/1.8.3/bin/svn GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/user/env/local/tools/svn/1.8.3/bin/svn...done. (gdb) run co http://svn.apache.org/repos/asf/subversion/trunk//tmp/KKLL Starting program: /home/user/env/local/tools/svn/1.8.3/bin/svn co http://svn.apache.or g/repos/asf/subversion/trunk/ /tmp/KKLL [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. A/tmp/KKLL/notes A/tmp/KKLL/notes/obliterate A/tmp/KKLL/notes/obliterate/fspec-cc1 A/tmp/KKLL/notes/obliterate/fspec-dd1 A/tmp/KKLL/notes/obliterate/hooks A/tmp/KKLL/notes/obliterate/presentations A/tmp/KKLL/notes/wc-ng A/tmp/KKLL/CHANGES A/tmp/KKLL/gen-make.py A/tmp/KKLL/autogen.sh A/tmp/KKLL/aclocal.m4 A/tmp/KKLL/NOTICE A/tmp/KKLL/get-deps.sh A/tmp/KKLL/Makefile.in A/tmp/KKLL/LICENSE A/tmp/KKLL/build.conf A/tmp/KKLL/win-tests.py A/tmp/KKLL/COMMITTERS A/tmp/KKLL/notes/obliterate/design-repos.html A/tmp/KKLL/notes/obliterate/fspec-cc1/cc1-dir-ops.svg A/tmp/KKLL/notes/obliterate/fspec-cc1/cc1-file-ops.svg A/tmp/KKLL/notes/obliterate/fspec-cc1/cc1-fspec.txt A/tmp/KKLL/notes/tree-conflicts A/tmp/KKLL/notes/feedback A/tmp/KKLL/notes/wc-ng/modularization Program received signal SIGSEGV, Segmentation fault. 0x7676486b in impl_pollset_poll (pollset=0x6bf050, timeout=optimized out, num=0x7fffdb94, descriptors=0x7fffdb98) at poll/unix/epoll.c:284 284 pollset-p-result_set[j] = *fdptr; (gdb) backtrace #0 0x7676486b in impl_pollset_poll (pollset=0x6bf050, timeout=optimized out, num=0x7fffdb94, descriptors=0x7fffdb98) at poll/unix/epoll.c:284 #1 0x74948cf6 in serf_context_run () from /home/user/env/local/tools/svn/1.8.3/lib/../../../../lib/libserf-1.so.3 #2 0x74b73988 in finish_report (report_baton=0x651e90, pool=optimized out) at subversion/libsvn_ra_serf/update.c:2850 #3 0x778ff0aa in svn_wc_crawl_revisions5 (wc_ctx=0x69d638, local_abspath=local_abspath@entry=0x64f338 /tmp/KKLL, reporter=0x74d82ef0, report_baton=0x651e90, restore_files=restore_files@entry=1, depth=depth@entry=svn_depth_unknown, honor_depth_exclude=1, depth_compatibility_trick=0, use_commit_times=0, cancel_func=0x4180a0 svn_cl__check_cancel, cancel_baton=0x0, notify_func=0x412d30 notify, notify_baton=0x69d778, scratch_pool=0x64f228) at subversion/libsvn_wc/adm_crawler.c:845 #4 0x77bcc726 in update_internal (result_rev=result_rev@entry =0x0, conflicted_paths=conflicted_paths@entry=0x650780, local_abspath=local_abspath@entry=0x64f338 /tmp/KKLL, anchor_abspath=0x650850 /tmp/KKLL, revision=revision@entry=0x7fffdf00, depth=depth@entry=svn_depth_unknown, depth_is_sticky=0, ignore_externals=0, allow_unver_obstructions=0, adds_as_modification=1, timestamp_sleep=0x7fffe064, notify_summary=1, ctx=0x69d580, pool=0x64f228) at subversion/libsvn_client/update.c:459 #5 0x77bccc44 in svn_client__update_internal (result_rev=result_rev@entry=0x0, local_abspath=local_abspath@entry=0x64f338 /tmp/KKLL, revision=revision@entry=0x7fffe0f0, depth=depth@entry=svn_depth_unknown, depth_is_sticky=depth_is_sticky@entry=1, ignore_externals=ignore_externals@entry=0, allow_unver_obstructions=0, adds_as_modification=1, make_parents=0, innerupdate=0, timestamp_sleep=0x7fffe064, ctx=0x69d580, pool=0x64f228) at subversion/libsvn_client/update.c:595 #6 0x77b97ebd in svn_client__checkout_internal (result_rev=result_rev@entry=0x0, url=url@entry=0x69e5f8 http://svn.apache.org/repos/asf/subversion/trunk;, local_abspath=0x64f338 /tmp/KKLL, peg_revision=0x7fffe100, revision=0x7fffe0f0,
Re: svn 1.8 client segmentation fault when checking out Subversion trunk repository
On Wednesday 09 of October 2013 20:33:25 you wrote:
Has anybody seen a similar issue or any idea what am I doing wrong when
compiling svn 1.8?
Did you per chance build serf with a different build of apr apr-util as
you used for Subversion?
Lieven
I build serf with the same version of apr apr-util as I did with Subversion.
apr 1.4.8 and apr-util 1.5.2.
I also tried different versions of serf: 1.2.1, 1.3.1, 1.3.2 but still no
difference.
Just to note, I had to patch apr to make it building with lsbcc. This is the
diff I use for building apr:
--- network_io/unix/sockopt.c.orig 2013-09-18 15:06:37.013013121 -0700
+++ network_io/unix/sockopt.c 2013-09-18 15:05:31.133012157 -0700
@@ -18,6 +18,9 @@
#include apr_strings.h
+#define SIOCATMARK 0x8905
+
+
static apr_status_t soblock(int sd)
{
/* BeOS uses setsockopt at present for non blocking... */
Not sure if this matters or not.
