Merging problem because of non recognized mergeinfo (probably caused by subversion 1.8.0)
Good morning, we have a serious merging problem, as I noticed that somehow the svn:mergeinfo got lost while merging I immediately stopped my merging steps and started over with new branches. Yesterday I came across following bugfix as it seems that I had the same problem: http://mail-archives.apache.org/mod_mbox/subversion-users/201309.mbox/%3c20130916142608.gk10...@larry.stsp.name%3E http://svn.apache.org/viewvc?view=revision&revision=r1523666 In this moment we have unfortunately three development lines: 1. the old code base, which is still on the live servers 2. the new code base: 2.1 the new trunk, where feature development is done 2.2 the stability and bugfix branch which is supposed to go live soon (let's call it 4.5, as this is the actual branch version) What I did now is: 1. Merge all bugfixes we did in the old codebase into the branch 4.5 mentioned in 2.2, we needed them there first 2. As something with the svn:mergeinfo went wrong, I stopped my attempted to merge anything else into our new trunk 3. I created a new branch, copied from 4.5, and merged all further development from the new trunk into this new branch (called reintegrate-trunk-into-4.5). I did this because I had problems before and I wanted a new, independent branch without breaking the branches where people are developing on. All this happened with subversion 1.8.0 (The server is on 1.7). I have now a ready branch, containing absolutely all commits I need, from the old code base, from 4.5 bug fixes and from the development in the new trunk. But I am not able to merge this into our new trunk back again, with following error messages: trunk$ svn merge https://URL/Projekte/fazcore/branches/reintegrate-trunk-into-4.5 . svn: E195016: Reintegrate can only be used if revisions 32893 through 33722 were previously merged from https://URL/Projekte/fazcore/trunk to the reintegrate source, but this is not the case: Projekte/fazcore/branches/reintegrate-trunk-into-4.5/common/src/main/java/de/faz/modules/query/filter/Filter.java Missing ranges: /Projekte/fazcore/trunk/common/src/main/java/de/faz/modules/query/filter/Filter.java:33577 ... (about 30-40 more of those errors) The fact is, that those revisions are merged into the reintegrate-trunk-into-4.5 branch already: reintegrate-trunk-into-4.5$ svn propget svn:mergeinfo . | grep 'fazcore/trunk' /Projekte/fazcore/trunk:32893-33722 Is there a way to "repair" this merge info so that it gets recognized when merging back into trunk? Or is there a way to force the merging anyway (beside --ignore-ancestry, I'd like to keep the merge history)? Or at least to merge the rest, excluding those problematic files? Thanks very much and best regards Paul.
Re: Merging problem because of non recognized mergeinfo (probably caused by subversion 1.8.0)
On Fri, Nov 1, 2013 at 8:55 AM, Paul Wellner Bou wrote: > Good morning, > > we have a serious merging problem, as I noticed that somehow the > svn:mergeinfo got lost while merging I immediately stopped my merging > steps and started over with new branches. Yesterday I came across > following bugfix as it seems that I had the same problem: > > http://mail-archives.apache.org/mod_mbox/subversion-users/201309.mbox/%3c20130916142608.gk10...@larry.stsp.name%3E > http://svn.apache.org/viewvc?view=revision&revision=r1523666 > > In this moment we have unfortunately three development lines: > > 1. the old code base, which is still on the live servers > 2. the new code base: > 2.1 the new trunk, where feature development is done > 2.2 the stability and bugfix branch which is supposed to go live > soon (let's call it 4.5, as this is the actual branch version) > > What I did now is: > > 1. Merge all bugfixes we did in the old codebase into the branch 4.5 > mentioned in 2.2, we needed them there first > 2. As something with the svn:mergeinfo went wrong, I stopped my > attempted to merge anything else into our new trunk > 3. I created a new branch, copied from 4.5, and merged all further > development from the new trunk into this new branch (called > reintegrate-trunk-into-4.5). I did this because I had problems before > and I wanted a new, independent branch without breaking the branches > where people are developing on. > > All this happened with subversion 1.8.0 (The server is on 1.7). > > I have now a ready branch, containing absolutely all commits I need, > from the old code base, from 4.5 bug fixes and from the development in > the new trunk. But I am not able to merge this into our new trunk back > again, with following error messages: > > trunk$ svn merge > https://URL/Projekte/fazcore/branches/reintegrate-trunk-into-4.5 . > svn: E195016: Reintegrate can only be used if revisions 32893 through > 33722 were previously merged from https://URL/Projekte/fazcore/trunk > to the reintegrate source, but this is not the case: > > Projekte/fazcore/branches/reintegrate-trunk-into-4.5/common/src/main/java/de/faz/modules/query/filter/Filter.java > Missing ranges: > /Projekte/fazcore/trunk/common/src/main/java/de/faz/modules/query/filter/Filter.java:33577 > ... > (about 30-40 more of those errors) > > The fact is, that those revisions are merged into the > reintegrate-trunk-into-4.5 branch already: > > reintegrate-trunk-into-4.5$ svn propget svn:mergeinfo . | grep 'fazcore/trunk' > /Projekte/fazcore/trunk:32893-33722 > > Is there a way to "repair" this merge info so that it gets recognized > when merging back into trunk? > Or is there a way to force the merging anyway (beside > --ignore-ancestry, I'd like to keep the merge history)? > Or at least to merge the rest, excluding those problematic files? Perhaps that filter/Filter.java path has subtree mergeinfo that is not correct somehow. Maybe it's missing the last character in some of the paths (like in the mail you referenced). I suggest you check the mergeinfo on that Filter.java path directly. Also, the bug that caused the missing last character in mergeinfo has been fixed in 1.8.4. See this post from a user who has confirmed, and seen his corrupt mergeinfo being fixed by a subsequent merge: http://svn.haxx.se/users/archive-2013-10/0216.shtml HTH -- Johan
Re: Subversion 1.7.13 mod_dav_svn with mod_wsgi auth causes Apache segfaults
I can confirm that this patch fixes. Thanks guys! Very good service, much appreciated. Regards, lph -- Larry Howard, Sr. Research Scientist Institute for Software Integrated Systems, Vanderbilt University On Oct 30, 2013, at 7:57 PM, Ben Reser wrote: > On 10/30/13 12:12 PM, Philip Martin wrote: >> Subversion's translate_name hook is setting r->filename to NULL and it >> appears that mod_wsgi does not check for NULL. > > Thanks Philip. When I made this change I expected that other modules would be > ok with r->filename being NULL. I guess that's not the case. > > I've fixed the problem on trunk in r1537360. Change has been nominated for > 1.7.x and 1.8.x backport. > > Larry, I've attached a patch which should resolve the problem for you. Thanks > for the report. > > smime.p7s Description: S/MIME cryptographic signature
How to determine subversion repository format
Hello,
I am getting this svn client message:
The working copy at
is too old (format 29) to work with client version '1.8.4 (r1534716)' (expects
format 31). You need to upgrade the working copy first.
I am interested in knowing where "format 29" is stored. My searches have lead
me to /.svn/{entries,format} which both contain a single line with
the value of "14" and .svn/wc.db which when dumped with sqlite3 "format 29"
does not stand out to me.
Can someone point me to some documentation which explains where the repository
format information is stored for various version of subversion.
I know in this case that I my repository was last updated by subversion 1.7.x
but nonetheless I would like to know how to get the existing repository format
info without upgrading or installing older versions of subversion until one
works with an unknown repository format.
Regards,
Bradley Giesbrecht (pixilla)
RE: How to determine subversion repository format
> I am getting this svn client message:
> The working copy at
> is too old (format 29) to work with client version '1.8.4 (r1534716)' (expects
> format 31). You need to upgrade the working copy first.
>
> I am interested in knowing where "format 29" is stored. My searches have
> lead me to /.svn/{entries,format} which both contain a single
> line with the value of "14" and .svn/wc.db which when dumped with sqlite3
> "format 29" does not stand out to me.
>
> Can someone point me to some documentation which explains where the
> repository format information is stored for various version of subversion.
>
> I know in this case that I my repository was last updated by subversion 1.7.x
> but nonetheless I would like to know how to get the existing repository
> format info without upgrading or installing older versions of subversion until
> one works with an unknown repository format.
>
>
> Regards,
> Bradley Giesbrecht (pixilla)
I'm pretty sure this message is talking about the WORKING COPY version, not the
repository version. Format 29 is probably the working copy format for 1.7.x.
BOb
Re: Subversion 1.7.13 mod_dav_svn with mod_wsgi auth causes Apache segfaults
On 10/30/13 5:57 PM, Ben Reser wrote: > On 10/30/13 12:12 PM, Philip Martin wrote: >> Subversion's translate_name hook is setting r->filename to NULL and it >> appears that mod_wsgi does not check for NULL. > > Thanks Philip. When I made this change I expected that other modules would be > ok with r->filename being NULL. I guess that's not the case. > > I've fixed the problem on trunk in r1537360. Change has been nominated for > 1.7.x and 1.8.x backport. > > Larry, I've attached a patch which should resolve the problem for you. Thanks > for the report. This same issue also impacts mod_hfs_apple on the Mac.
svnserve crashes in libdispatch on OS X Mavericks (10.9) server
Upgraded to 10.9 server and reinstalled macports (2.2.1) and subversion, version 1.8.4. Can't use subversion locally or with svnserve from another client. Here's the svnserve crash report: Process: svnserve [3143] Path:/opt/local/bin/svnserve Identifier: svnserve Version: 0 Code Type: X86-64 (Native) Parent Process: svnserve [106] Responsible: svnserve [3143] User ID: 0 Date/Time: 2013-10-30 14:41:14.001 -0400 OS Version: Mac OS X 10.9 (13A603) Report Version: 11 Anonymous UUID: 39D61124-0FC0-E91F-DEF6-978DDEB0A504 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0110 VM Regions Near 0x110: --> __TEXT 000108a9-000108aa2000 [ 72K] r-x/rwx SM=COW /opt/local/bin/svnserve Application Specific Information: *** single-threaded process forked *** crashed on child side of fork pre-exec Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libdispatch.dylib 0x7fff95b3f206 _dispatch_wakeup + 100 1 libdispatch.dylib 0x7fff95b3f7a8 _dispatch_queue_push_list_slow2 + 30 2 libdispatch.dylib 0x7fff95b42145 _dispatch_mach_msg_send + 608 3 libdispatch.dylib 0x7fff95b41e99 dispatch_mach_send + 136 4 libxpc.dylib0x7fff8d232864 _xpc_connection_send_message_with_reply_f + 125 5 libxpc.dylib0x7fff8d232724 xpc_connection_send_message_with_reply_sync + 180 6 com.apple.CoreFoundation0x7fff8ff6b193 -[CFPrefsPlistSource copyReplyForDaemonMessage:toConnection:error:] + 243 7 com.apple.CoreFoundation0x7fff900c5820 __47-[CFPrefsPlistSource alreadylocked_synchronize]_block_invoke_2 + 352 8 com.apple.CoreFoundation0x7fff8ff6aa9b withDaemonConnection + 299 9 com.apple.CoreFoundation0x7fff8ff6a4fb -[CFPrefsPlistSource alreadylocked_synchronize] + 587 10 com.apple.CoreFoundation0x7fff8ff6a1f3 _copyValueForKey + 131 11 com.apple.CoreFoundation0x7fff8ff6a147 -[CFPrefsPlistSource copyValueForKey:] + 71 12 com.apple.CoreFoundation0x7fff8ff69fa5 -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 149 13 com.apple.CoreFoundation0x7fff8ff69edf -[CFPrefsSource copyValueForKey:] + 79 14 com.apple.CoreFoundation0x7fff8ff69e70 __CFPreferencesCopyAppValue_block_invoke + 32 15 com.apple.CoreFoundation0x7fff8ff6404e +[CFPrefsSearchListSource withSearchListForIdentifier:perform:] + 846 16 com.apple.CoreFoundation0x7fff8ff63cb8 CFPreferencesCopyAppValue + 168 17 libintl.8.dylib 0x000108e55598 _nl_language_preferences_default + 70 18 libintl.8.dylib 0x000108e539ea libintl_dcigettext + 894 19 libsvn_subr-1.0.dylib 0x000108c8397c do_io_file_wrapper_cleanup + 118 20 libsvn_subr-1.0.dylib 0x000108c83bb8 stringbuf_from_aprfile + 283 21 libsvn_subr-1.0.dylib 0x000108c83a66 svn_stringbuf_from_file2 + 151 22 libsvn_fs_fs-1.0.dylib 0x000108afc718 read_format + 52 23 libsvn_fs_fs-1.0.dylib 0x000108afc601 svn_fs_fs__open + 94 24 libsvn_fs_fs-1.0.dylib 0x000108afbb8f fs_open + 84 25 libsvn_fs-1.0.dylib 0x000108ae7ed5 svn_fs_open + 173 26 libsvn_repos-1.0.dylib 0x000108ac571b get_repos + 135 27 libsvn_repos-1.0.dylib 0x000108ac568e svn_repos_open2 + 33 28 svnserve0x000108a98463 serve + 2094 29 svnserve0x000108a9f30f main + 4355 30 libdyld.dylib 0x7fff8e5745fd start + 1 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0100 rbx: 0x7fbe9b501bb0 rcx: 0x0003 rdx: 0x0001 rdi: 0x7fbe9b501bb0 rsi: 0x7fbe9b504490 rbp: 0x7fff5716eeb0 rsp: 0x7fff5716eea0 r8: 0x r9: 0x r10: 0x r11: 0x0206 r12: 0x7fbe9b501bb0 r13: 0x0607 r14: 0x7fff7e2796c0 r15: 0x7fbe9b501bf0 rip: 0x7fff95b3f206 rfl: 0x00010206 cr2: 0x0110 Logical CPU: 0 Error Code: 0x0006 Trap Number: 14 Binary Images: 0x108a9 -0x108aa1fff +svnserve (0) /opt/local/bin/svnserve 0x108aac000 -0x108ad2fff +libsvn_repos-1.0.dylib (0) /opt/local/lib/libsvn_repos-1.0.dylib 0x108ae1000 -0x108ae9fff +libsvn_fs-1.0.dylib (0) <2719E39C-9968-37DE-B33F-CCB00297B399> /opt/local/lib/libsvn_fs-1.0.dylib 0x108af5000 -0x108b1afff +libsvn_fs_fs-1.0.dylib (0) /opt/local
Segmentation fault in webdav after upgrading to 1.7 on CentOS - Need new ideas
Hi, We upgraded subversion from 1.6 to 1.7, but can't get the WebDAV online anymore. As far as we can see everything appears to be set up correctly. Would appreciate if somebody could give a pointer or two on how to debug this further. OS: CENTOS 6.4 x86_64 SVN: subversion 1.7.13 svn is build with: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-apr=/usr/local/apache --with-apr-util=/usr/local/apache --with-ssl && make && make install This is included from httpd.conf: LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so DAV svn SVNParentPath /var/svn/repos AuthzSVNAccessFile /etc/svn-acl-conf AuthType Basic AuthName "My repository" AuthUserFile /etc/svn-auth-conf Require valid-user Apache error_log [Fri Nov 01 19:26:09 2013] [notice] SSL FIPS mode disabled [Fri Nov 01 19:26:09 2013] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec) [Fri Nov 01 19:26:09 2013] [notice] ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) configured. [Fri Nov 01 19:26:09 2013] [notice] ModSecurity: APR compiled version="1.4.6"; loaded version="1.4.6" [Fri Nov 01 19:26:09 2013] [notice] ModSecurity: PCRE compiled version="8.21 "; loaded version="8.21 2011-12-12" [Fri Nov 01 19:26:09 2013] [notice] ModSecurity: LIBXML compiled version="2.9.0" [Fri Nov 01 19:26:10 2013] [notice] SSL FIPS mode disabled [Fri Nov 01 19:26:10 2013] [notice] Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 SVN/1.7.13 configured -- resuming normal operations [Fri Nov 01 19:26:27 2013] [notice] child pid 1473 exit signal Segmentation fault (11) [Fri Nov 01 19:26:29 2013] [notice] child pid 1548 exit signal Segmentation fault (11) [Fri Nov 01 19:26:31 2013] [notice] child pid 1615 exit signal Segmentation fault (11) [Fri Nov 01 19:26:33 2013] [notice] child pid 1683 exit signal Segmentation fault (11) I am lost. Any suggestions are greatly appreciated. Kind Regards, Erwin
Re: Segmentation fault in webdav after upgrading to 1.7 on CentOS - Need new ideas
On 11/1/13 9:20 PM, Erwin Hogeweg wrote: > We upgraded subversion from 1.6 to 1.7, but can't get the WebDAV online > anymore. As far as we can see everything appears to be set up correctly. Would > appreciate if somebody could give a pointer or two on how to debug this > further. Give the patch here a try: https://mail-archives.apache.org/mod_mbox/subversion-users/201310.mbox/%3C5271AB05.5050802%40reser.org%3E
