Re: overriding .subversion/config[helpers] on the command line
On Tue, Oct 14, 2014 at 5:00 AM, Perry Hutchison wrote: > Stefan Sperling wrote: >> On Fri, Oct 10, 2014 at 10:27:46AM +0200, Stefan Sperling wrote: >> > On Fri, Oct 10, 2014 at 12:53:16AM -0700, Perry Hutchison wrote: >> > > ... >> > > It appears that I can override the diff3-cmd setting by adding >> > > --diff3-cmd=/bin/false to the command, but when I try to do the >> > > same thing to merge-tool-cmd (by adding --merge-tool-cmd=/bin/false) >> > > I get an error message: >> > > >> > > svn: invalid option: --merge-tool-cmd=/bin/false >> > > >> > > How do I go about overriding the merge-tool-cmd setting on the svn >> > > command line? >> > > >> > > svn version 1.6.17 (r1128011) on Ubuntu 12.04, in case it matters. >> > > >> > > Please Cc. >> > >> > Try --config-option:config:global:merge-tool-cmd=/bin/false >> >> Sorry, got the section name wrong: >> --config-option:config:helpers:merge-tool-cmd=/bin/false > > I wonder if that option may be new in 1.7 -- it doesn't seem to be > recognized in 1.6.17: > > svn: invalid option: --config-option:config:helpers:merge-tool-cmd=/bin/false I think it needs to be: --config-option config:helpers:merge-tool-cmd=/bin/false (i.e. a space after --config-option, not a colon) -- Johan
Re: svn: E200030: sqlite: Expected database row missing
Alexey Neyman writes: > On 10/13/2014 04:08 PM, Andreas Stieger wrote: >> Hello, >> >> On 09/10/14 23:48, Alexey Neyman wrote: >>> What I was doing: >>> >>> - checked out a project from /trunk >>> - did some local changes >>> - copied WC to a branch >>> - attempted to switch to the branch >> What exactly does "copied WC to a branch" mean in terms of svn or file >> system operations? > It means exactly that, copying from a WC to a new directory in the repository: > > $ svn cp . ^/engr/aneyman/mybranch That's a commit. Did it succeed? If so then the commit should contain a lot of information about the state of the working copy. What does the commit look like? What does 'svn log -v' show for the commit? Adds, modifications, copies, deletes, property changes, etc.? The tables in the SQLite database .svn/wc.db have some incorrect content but it is hard to guess exactly what is wrong. The working copy is complicated and you have provided little information. If there was no corruption what sort of local changes do you expect? Adds, deletes, property changes, etc.? Are there file or directory externals? Do they have changes? Are you able to identify which paths in the working copy trigger the problem? Try running "svn st path", or "svn info path", for various paths in the working copy, and see which succeed/fail. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
SVN 1.8 timeout fix
We just upgraded from Subversion 1.7 to 1.8 and almost immediately began getting timeouts checking out larger repositories. The Tortoise file transfer rate would quickly diminish to 0 and eventually return an error. The subversion command client would terminate with "svn E175012 Connection timed out." I found several reports from other who encountered the same thing, but there were no solutions offered. Some people said they simply reverted back to 1.7. I monitored the network traffic and saw the tcp connections were opened and remained in the FIN_WAIT_2 state. http://httpd.apache.org/docs/2.0/misc/fin_wait_2.html suggests a client side bug and to set KeepAlive Off if you're unable to make mods to your client. Setting KeepAlive Off on my apache server fixed the issue. Paul Gillis Engineering Support Specialist L-3 Warrior Systems, Insight 9 Akira Way, Londonderry, NH 03053 (603) 551-6167 paul.gil...@l-3com.com
SVN 1.8.8 - svn: E175012: Connection timed out
On your Apache server, set KeepAlive Off Paul Gillis Engineering Support Specialist L-3 Warrior Systems, Insight 9 Akira Way, Londonderry, NH 03053 (603) 551-6167 paul.gil...@l-3com.com
Re: SVN 1.8 timeout fix
writes: > We just upgraded from Subversion 1.7 to 1.8 and almost immediately > began getting timeouts checking out larger repositories. The Tortoise > file transfer rate would quickly diminish to 0 and eventually return > an error. The subversion command client would terminate with "svn > E175012 Connection timed out." I found several reports from other who > encountered the same thing, but there were no solutions offered. Some > people said they simply reverted back to 1.7. I assume you are referring to an upgrade of the client from 1.7 to 1.8. Did you also upgrade the server? Which version is running on the server? One change in 1.8 is that serf is used to handle HTTP on the client-side rather than neon. The default client-side HTTP timeout when using neon is 60 minutes but when using serf it is 10 minutes. A client can change its default timeout by setting servers:global:http-timeout. If you upgraded the server to 1.8 then update/checkout will have switched to skelta-mode by default and I suppose configuring the client or server to use bulk-mode might solve the problem: http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: svn: E200030: sqlite: Expected database row missing
On 10/14/2014 05:03 AM, Philip Martin wrote: Alexey Neyman writes: On 10/13/2014 04:08 PM, Andreas Stieger wrote: Hello, On 09/10/14 23:48, Alexey Neyman wrote: What I was doing: - checked out a project from /trunk - did some local changes - copied WC to a branch - attempted to switch to the branch What exactly does "copied WC to a branch" mean in terms of svn or file system operations? It means exactly that, copying from a WC to a new directory in the repository: $ svn cp . ^/engr/aneyman/mybranch That's a commit. Did it succeed? If so then the commit should contain a lot of information about the state of the working copy. What does the commit look like? What does 'svn log -v' show for the commit? Adds, modifications, copies, deletes, property changes, etc.? Yes, it is a commit and it has succeeded. If I check out a separate working copy from that new path, it is fine and contains all the modifications from the working copy thus checked in. Actually, looking at the commit I came up with a reproduction scenario: [[[ #!/bin/bash cd /tmp svnadmin create repo svn co file://`pwd`/repo wc svn mkdir wc/trunk wc/trunk/d1 wc/trunk/d2 echo hi > wc/trunk/d1/f1 svn add wc/trunk/d1/f1 svn ci -mm wc rm -rf wc svn co file://`pwd`/repo/trunk wc svn mv wc/d1/f1 wc/d2 svn rm wc/d1 svn cp -mm wc file://`pwd`/repo/newbranch svn switch file://`pwd`/repo/newbranch wc ]]] Running this script under SVN 1.8.10 gives the same "missing row" error. So, the problem operation is "copy a file from a directory, then delete that directory". Checked the issue using SVN trunk. It does not abort like 1.8.10, but it does report tree conflicts for d1/f1 and d1. I would say such conflicts should be resolved automatically, given that the working copy contains exactly the same changes as in the incoming edit. Figuring that out may not be trivial, though, as the copied directory may be arbitrarily deep. Regards, Alexey.
Wait for hours when commit or update a larger .unity file
Hello, I have a problem with using SVN. Here is the situation: I am a Unity3D user, and I have to wait for hours when I commit or update a very large * .unity file with SVN. The file is about 100M or so. Can you guys let me what happened when a very large file is committed or updated? I will appreciate it very much if there are any great suggestions. Thanks, Chao
Re: Wait for hours when commit or update a larger .unity file
On 15.10.2014 05:03, Chao.Guan wrote: > Hello, > > I have a problem with using SVN. > > Here is the situation: > I am a Unity3D user, and I have to wait for hours when I commit or update a > very large * .unity file with SVN. The file is about 100M or so. That's strange; 100M isn't really "huge" that it should take hours to commit. > Can you guys let me what happened when a very large file is committed or > updated? > I will appreciate it very much if there are any great suggestions. First of all we need to know which version of Subversion you're using (client and server), how your server is set up and how you're accessing it (http:// vs. svn://, for example), client and server platform; and not least, the quality of your network connection to the server. Further questions may follow after that. :) -- Brane
