Re: Can't kill svn
On Fri, Jun 01, 2012 at 06:19:58PM -0400, Michael P. Reilly wrote: > On Fri, Jun 1, 2012 at 3:13 PM, Andreas Krey wrote: > > > Hi everybody, > > > > is there already a bug on this? I can't always get the svn client to > > stop using ^C. Mostly this seems to happen with slow network I/O, like, > > for reproduction: > > > > prompt> time svn checkout http://217.140.74.17/doesnotexist > > ^C^C^Csvn: OPTIONS of 'http://217.140.74.17/doesnotexist': could not > > connect to server (http://217.140.74.17) > > > > real 1m14.898s > > user 0m0.007s > > sys 0m0.006s > > prompt> > > > > I hit ^C shortly after hitting enter, but 1) svn doesn't stop > > and 2) doesn't even seem to care about the signal received. > > > > The only way to actually get rid of it is to ^Z and 'kill -9 %', > > but this then requires a cleanup occasionally (plus the prayer > > that the latter will work). > > > > Andreas > > > > What release of Subversion and what is your operating system? Standard > network has a timeout of about 120 seconds, but depending on the OS, the > command may not be interrupt-able until that timeout. > I believe this is neon blocking on socket I/O for a fixed timeout and not returning to Subversion code until after the timeout has expired. Some signals never have an immediate effect in Subversion. Subversion handles signals gracefully at defined points to ensure state is cleaned up properly. When the signal is received, a flag is set that is checked next time Subversion invokes the cancellation handler which then cleans up state and causes an exit. It seems using serf improves signal response time in this case, at least with recent enough serf releases. It won't block on the socket as long as neon does.
Re: Issues with externals
On Fri, Jun 01, 2012 at 11:58:40AM -0600, Philip Prindeville wrote: > I take it there's no way to backport a fix to 1.6.x? We do not fix bugs in 1.6 anymore that aren't security problems or cause data corruption: http://subversion.apache.org/docs/release-notes/#supported-versions The 1.7 release has a rewritten working copy library, in particular to address working copy problems. If you need working copy bug fixes, please upgrade to 1.7.
Re: Binary blob corruption
On Fri, Jun 01, 2012 at 03:39:07PM +0200, Thorsten Schöning wrote: > Guten Tag Skylar Thompson, > am Freitag, 1. Juni 2012 um 15:00 schrieben Sie: > > > I've attached a script file that demonstrates this. > > I have some strange characters i you file after saving it from my mail > client The Bat!, maybe you should repost a zipped version unless I'm > the only one with this problem. Those are 'backspace' characters. The script program that created this file captures those and saves them in its output. And the poster didn't sanitize the output before posting. >From the script(1) man page: BUGS script places everything in the log file, including linefeeds and backspaces. This is not what the naive user expects.
Re: Problem in connecting the server
On Sat, Jun 02, 2012 at 07:24:54AM +0900, Masaru Kitajima wrote: > Stefan, > > I double checked all httpd configuration files, but there was > no RedirectMatch for /svn location. > > About Project1, I created new repository to check if the project > repository was broken. Do you have any other Location statements in your configuration? Do you run anything else on this server than Subversion, such as another website? If so, please disable the other sites and check if Subversion works then. If this fixes the problem, try to re-enable the other sites until you find the one that breaks Subversion, and then show us the configuration of that site, and the Subversion configuration. (I know you posted your SVN configuration parts already, but to a different thread. It is better to have all in the same thread. In the future, if you do not get an answer to a question, please reply to your own post instead of starting a new thread. This way, the archives will keep all related information linked in a single thread. Thanks!)
Re: Problem in connecting the server
Stefan, I have one website configuration and its document root is /var/www/html/. This is where I want to put the php files. No other website is configured. And I want to manage there versions with subversion and its repository is /lib/svn/project. Do you recommend to disable /var/www/html/? On 2012/06/02, at 18:29, Stefan Sperling wrote: > On Sat, Jun 02, 2012 at 07:24:54AM +0900, Masaru Kitajima wrote: >> Stefan, >> >> I double checked all httpd configuration files, but there was >> no RedirectMatch for /svn location. >> >> About Project1, I created new repository to check if the project >> repository was broken. > > Do you have any other Location statements in your configuration? > > Do you run anything else on this server than Subversion, such as > another website? If so, please disable the other sites and check if > Subversion works then. If this fixes the problem, try to re-enable > the other sites until you find the one that breaks Subversion, and > then show us the configuration of that site, and the Subversion > configuration. > > (I know you posted your SVN configuration parts already, but to a different > thread. It is better to have all in the same thread. In the future, if you > do not get an answer to a question, please reply to your own post instead of > starting a new thread. This way, the archives will keep all related > information linked in a single thread. Thanks!)
Re: Binary blob corruption
On 06/02/12 02:21, Stefan Sperling wrote: > On Fri, Jun 01, 2012 at 03:39:07PM +0200, Thorsten Schöning wrote: > >> Guten Tag Skylar Thompson, >> am Freitag, 1. Juni 2012 um 15:00 schrieben Sie: >> >> >>> I've attached a script file that demonstrates this. >>> >> I have some strange characters i you file after saving it from my mail >> client The Bat!, maybe you should repost a zipped version unless I'm >> the only one with this problem. >> > Those are 'backspace' characters. The script program that created this > file captures those and saves them in its output. And the poster didn't > sanitize the output before posting. > > From the script(1) man page: > > BUGS > script places everything in the log file, including linefeeds and > backspaces. This is not what the naive user expects. > > Indeed, apologies. In less it looks fine, but I'll use screen's terminal capture going forward. I think that won't get terminal characters. Skylar
Re: Binary blob corruption
On 06/01/12 06:43, Philip Martin wrote: > Skylar Thompson writes: > > >> [skylar@hopper ~]$ svnadmin[Kmkdir svnrepo >> [skylar@hopper ~]$ svnadmin create svnrepo >> [skylar@hopper ~]$ mkdir svn >> [skylar@hopper ~]$ cd svn >> [skylar@hopper ~/svn]$ svn co file:///cluster/home/skylar/svnrepo/ >> Authentication realm: c328e328-e9ab-e111-bfb4-001e687902b7 >> Username: skylar >> Checked out revision 0. >> [skylar@hopper ~/svn]$ ls >> svnrepo >> [skylar@hopper ~/svn]$ cd svnrepo/ >> [skylar@hopper ~/svn/svnrepo]$ ls -l ~/tmp/icc >> -rwxr-xr-x 1 skylar users 3873673 Jun 1 05:55 >> /cluster/home/skylar/tmp/icc >> > That's the original file. > > >> [skylar@hopper ~/svn/svnrepo]$ cp ~/tmp/icc . >> > That's the copied file. You don't appear to have verified that the copy > is the same as the original. Are they different? Run something like > "sha1sum icc" to get checksums. > > >> [skylar@hopper ~/svn/svnrepo]$ svn add iuc[Kicc >> A (bin) icc >> [skylar@hopper ~/svn/svnrepo]$ svn - commit -m "test" >> Adding (bin) icc >> Transmitting file data . >> Committed revision 1. >> [skylar@hopper ~/svn/svnrepo]$ rm -f icc >> [skylar@hopper ~/svn/svnrepo]$ svn update >> Updating '.': >> Restored 'icc' >> At revision 1. >> [skylar@hopper ~/svn/svnrepo]$ ls -l >> total 3808 >> -rwxr-xr-x 1 skylar users 3873654 Jun 1 05:57 icc >> > That's the restored file. It should be the same as the copied file but > you don't appear to have checked that. It will only be the same as the > original file if the copy was the same as the original file. > > The big thing is they're different sizes, but I probably should have done a checksum as well. I've attached another round that shows the file changes on commit. Skylar mkdir svnrepo [skylar@hopper ~]$ svnadmin create svnrepo [skylar@hopper ~]$ mkdir svn [skylar@hopper ~]$ cd svn [skylar@hopper ~/svn]$ svbn n co file:///cluster/home/skylar/svnrepo Authentication realm: 905452c1-c9ac-e111-9bd8-001e687902b7 Username: skylar Checked out revision 0. [skylar@hopper ~/svn]$ cd svnrepo/ [skylar@hopper ~/svn/svnrepo]$ sha1 ~/tmp/icc SHA1 (/cluster/home/skylar/tmp/icc) = 29e1d247ac5b518537495ebda3df378fd5025a1b [skylar@hopper ~/svn/svnrepo]$ cp ~/tmp/icc . [skylar@hopper ~/svn/svnrepo]$ cp ~/tmp/icc .sha1 ~/tmp/icc[Kicc SHA1 (icc) = 29e1d247ac5b518537495ebda3df378fd5025a1b [skylar@hopper ~/svn/svnrepo]$ svn add icc A (bin) icc [skylar@hopper ~/svn/svnrepo]$ sha1 icc SHA1 (icc) = 29e1d247ac5b518537495ebda3df378fd5025a1b [skylar@hopper ~/svn/svnrepo]$ svn commit -m "adding" Adding (bin) icc Transmitting file data . Committed revision 1. ^[[A^[[A[skylar@hopper ~/svn/svnrepo]$ svn commit -m "adding" ha1 icc[K[3@vn add icc[3Pha1 icc SHA1 (icc) = 1637fef82fb8ae42307dd9edeba3c6ed50bbe0a0 [skylar@hopper ~/svn/svnrepo]$ rm -f icc [skylar@hopper ~/svn/svnrepo]$ svn update icc Updating 'icc': Restored 'icc' At revision 1. [skylar@hopper ~/svn/svnrepo]$ svn update icc[5Prm -f icc[1Psha1 icc SHA1 (icc) = 1637fef82fb8ae42307dd9edeba3c6ed50bbe0a0 [skylar@hopper ~/svn/svnrepo]$
Re: Problem in connecting the server
On Sat, Jun 02, 2012 at 07:39:46PM +0900, Masaru Kitajima wrote: > Stefan, > > I have one website configuration and its document root is /var/www/html/. > This is where I want to put the php files. No other website is configured. > > And I want to manage there versions with subversion and its repository > is /lib/svn/project. > > Do you recommend to disable /var/www/html/? Yes. Please try to disable the other website and check if that makes the problem go away. What URL do you use to access the website? Is the website at '/' ? Please make sure that and the website location do not overlap. Else, Apache HTTPD might mis-route requests destined for Subversion to the website, and vice-versa. Qutoing http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html Be sure that when you define your new Location, it doesn't overlap with other exported locations. For example, if your main DocumentRoot is exported to /www, do not export a Subversion repository in . If a request comes in for the URI /www/repos/foo.c, Apache won't know whether to look for a file repos/foo.c in the DocumentRoot, or whether to delegate mod_dav_svn to return foo.c from the Subversion repository. The result is often an error from the server of the form 301 Moved Permanently.
Re: Can't kill svn
On Sat, 02 Jun 2012 11:14:16 +, Stefan Sperling wrote: ... > Some signals never have an immediate effect in Subversion. > Subversion handles signals gracefully at defined points to ensure state > is cleaned up properly. Hanging more than a minute isn't exactly what I consider 'graceful'. > When the signal is received, a flag is set that > is checked next time Subversion invokes the cancellation handler which > then cleans up state and causes an exit. No, it doesn't. With 1.7.4: | a:cc-svn-7 andreaskrey$ svn17 up -r85321 | Updating '.': | Dtools | Uivy.xml | Usrc/ | U . | | Fetching external item into 'ioc': | Dmoda/CHANGES | Umoda/h/... (redacted output lists) | Umoda/src/... | ^Csvn: E200015: Caught signal Ok, it did terminate, and fast. But there is no 'graceful' in here: | a:cc-svn-7 andreaskrey$ svn17 up -r85321 | Updating '.': | | Fetching external item into 'ioc': | svn: warning: W155004: Working copy '/Users/andreaskrey/cc-svn-7/ioc' locked. ...and that situation persists. "graceful" != "requiring manual intervention, as with 'svn cleanup'". I only see the point of an arbitrary wait when svn then at least leaves the sandbox in a state that doesn't require cleanup. Incidentally, I only found that because I wanted to see if there is still the cascade of | svn: warning: Error handling externals definition for 'moda': | svn: warning: Caught signal | svn: warning: Error handling externals definition for 'modb': | svn: warning: Caught signal | svn: warning: Error handling externals definition for 'etc': | svn: warning: Caught signal | svn: warning: Error handling externals definition for 'ant-scripts': | svn: warning: Caught signal for a single ^C. Instead the wc is borked with: | svn: Failed to add directory 'tools': an unversioned directory of the same name already exists and a spurious conflict on svn:externals on the root (this with 1.6.6). (svn is 1.6.6, svn17 is 1.7.4.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Can't kill svn
On Sat, Jun 02, 2012 at 10:01:42PM +0200, Andreas Krey wrote: > On Sat, 02 Jun 2012 11:14:16 +, Stefan Sperling wrote: > ... > > Some signals never have an immediate effect in Subversion. > > Subversion handles signals gracefully at defined points to ensure state > > is cleaned up properly. > > Hanging more than a minute isn't exactly what I consider 'graceful'. > > > When the signal is received, a flag is set that > > is checked next time Subversion invokes the cancellation handler which > > then cleans up state and causes an exit. > > No, it doesn't. With 1.7.4: > > | a:cc-svn-7 andreaskrey$ svn17 up -r85321 > | Updating '.': > | Dtools > | Uivy.xml > | Usrc/ > | U . > | > | Fetching external item into 'ioc': > | Dmoda/CHANGES > | Umoda/h/... > (redacted output lists) > | Umoda/src/... > | ^Csvn: E200015: Caught signal > > Ok, it did terminate, and fast. > > But there is no 'graceful' in here: > > | a:cc-svn-7 andreaskrey$ svn17 up -r85321 > | Updating '.': > | > | Fetching external item into 'ioc': > | svn: warning: W155004: Working copy '/Users/andreaskrey/cc-svn-7/ioc' > locked. > > ...and that situation persists. "graceful" != "requiring manual > intervention, as with 'svn cleanup'". > > I only see the point of an arbitrary wait when svn then at least leaves > the sandbox in a state that doesn't require cleanup. > > Incidentally, I only found that because I wanted to see if there is > still the cascade of > > | svn: warning: Error handling externals definition for 'moda': > | svn: warning: Caught signal > | svn: warning: Error handling externals definition for 'modb': > | svn: warning: Caught signal > | svn: warning: Error handling externals definition for 'etc': > | svn: warning: Caught signal > | svn: warning: Error handling externals definition for 'ant-scripts': > | svn: warning: Caught signal > > for a single ^C. Instead the wc is borked with: > > | svn: Failed to add directory 'tools': an unversioned directory of the same > name already exists > > and a spurious conflict on svn:externals on the root (this with 1.6.6). > (svn is 1.6.6, svn17 is 1.7.4.) Yes, that looks like bad behaviour (externals again... *sigh*) Can you please file detailed reports for these problems in the issue tracker so they don't get lost? Thanks.
Re: Can't kill svn
On Fri, 01 Jun 2012 18:19:58 +, Michael P. Reilly wrote: ... > What release of Subversion and what is your operating system? 1.6.6 and 1.7.4, behaving essentially similar. MacOS 10.5.8. > Standard > network has a timeout of about 120 seconds, but depending on the OS, the > command may not be interrupt-able until that timeout. ...this being a 'feature' of svn, not the OS. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Problem in connecting the server
Stefan, First of all, I really appreciate your continuing helps. I'm new to subversion and server configuration, your helps are very appreciated. To disable /var/www/html/, is it OK to comment out the document root setting in httpd.conf and section? My website location is http://www.hakodate-night.info. This is where /var/www/html/. And my subversion location is /var/lib/svn/ and accessible form http://www.hakodate-night.info/svn/ikasu . "ikasu" is the real name of project. /var/lib/svn/ is protected by .htpasswd. If you kindly check it, I'll disable the auth related settings for /var/lib/svn. Anyway, I'll try to disable the /var/www/html/ first. Thanks again, Kindest regards, Masaru On 2012/06/03, at 1:07, Stefan Sperling wrote: > On Sat, Jun 02, 2012 at 07:39:46PM +0900, Masaru Kitajima wrote: >> Stefan, >> >> I have one website configuration and its document root is /var/www/html/. >> This is where I want to put the php files. No other website is configured. >> >> And I want to manage there versions with subversion and its repository >> is /lib/svn/project. >> >> Do you recommend to disable /var/www/html/? > > Yes. Please try to disable the other website and check if that > makes the problem go away. > > What URL do you use to access the website? Is the website at '/' ? > > Please make sure that and the website location do > not overlap. Else, Apache HTTPD might mis-route requests destined > for Subversion to the website, and vice-versa. > > Qutoing http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html > Be sure that when you define your new Location, it doesn't overlap with other > exported locations. For example, if your main DocumentRoot is exported to > /www, > do not export a Subversion repository in . If a request > comes in for the URI /www/repos/foo.c, Apache won't know whether to look for > a > file repos/foo.c in the DocumentRoot, or whether to delegate mod_dav_svn to > return foo.c from the Subversion repository. The result is often an error > from > the server of the form 301 Moved Permanently.
