Re: subversion windows passwords not stored
I tried SilkSVN and win32svn in Version 1.8.5 on my Windows 8.1 64-bit laptop. Both showed the same behavior. On Tue, Jan 7, 2014 at 11:20 PM, Ben Reser wrote: > On 1/7/14, 10:43 AM, darkdragon wrote: > > I am using Subversion 1.8.5 under Windows 8.1 and my passwords (http > repo) are > > not stored. > > I'm assuming you're using a binary package of some sort. Which binary > package > are you using? > >
Re: subversion windows passwords not stored
On 1/7/14, 10:43 AM, darkdragon wrote: > I am using Subversion 1.8.5 under Windows 8.1 and my passwords (http repo) are > not stored. I'm assuming you're using a binary package of some sort. Which binary package are you using?
Re: subversion windows passwords not stored
Yes, I have full access and am also the owner of the directories / files -.- On Tue, Jan 7, 2014 at 8:53 PM, Andrew Reedick wrote: > Do you have write access to the dirs/files in > %APPDATA%\Subversion\auth\...? > > > > I’ve seen cases on the Unix side where the cached auth files magically > become readonly (444) which prevents password caching. Very annoying. > > > > > > *From:* darkdragon [mailto:darkdragon-...@web.de] > *Sent:* Tuesday, January 07, 2014 1:43 PM > *To:* users@subversion.apache.org > *Subject:* subversion windows passwords not stored > > > > I am using Subversion 1.8.5 under Windows 8.1 and my passwords (http repo) > are not stored. > > > > I tried the default config (default options) and also explicitly setting > all related options. > > > > Both did not work. > > > > I also tried setting the option manually via "--config-option" - but also > without success! > > > > Further, I tried adding a server specific configuration. Options like > username were applied, options like store-passwords did not make a change. > > > > During my research, I noted that only the "%APPDATA%\Subversion" directory > exists (not the site-wide configuration and none of the registry keys > exists). > > > > Has anyone else Windows an can confirm this? > > > > Thanks! >
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
On Tue, Jan 7, 2014 at 8:44 PM, Ryan Schmidt wrote: > On Jan 7, 2014, at 12:01, Mojca Miklavec wrote: >> On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote: >> >>> Which version of Apache are you using? Which Apache MPM are you using? >> >> Server version: Apache/2.4.7 (Unix) >> >> I'm not sure how to check MPM. I get >> >>> httpd -l >> Compiled in modules: >> core.c >> mod_so.c >> http_core.c >> >> but "httpd -V" as suggested on some websites doesn't work. How should >> I check which MPM is being used? > > In what way does “httpd -V” not work? In this way: > httpd -V [] [so:warn] [pid 63924] AH01574: module dav_svn_module is already loaded, skipping [] [so:warn] [pid 63924] AH01574: module authz_svn_module is already loaded, skipping AH00548: NameVirtualHost has no effect and will be removed in the next release /path/to/00-vhosts.conf:1 (13)Permission denied: AH02291: Cannot access directory '/path/to/logs/1/' for error log of vhost defined at /path/to/20-another.conf:4 ... ... (repeats a bunch of times) ... AH00014: Configuration check failed But I saw the trick now. It wants me to use "sudo httpd -V" for some reason, then it works. And yes, it's "prefork" in my case as well, but that's probably no longer relevant now that one mystery with forgotten Apache restart was solved. (The other problem with "Error retrieving REPORT" is still a mystery though.) Mojca
RE: subversion windows passwords not stored
Do you have write access to the dirs/files in %APPDATA%\Subversion\auth\...? I’ve seen cases on the Unix side where the cached auth files magically become readonly (444) which prevents password caching. Very annoying. From: darkdragon [mailto:darkdragon-...@web.de] Sent: Tuesday, January 07, 2014 1:43 PM To: users@subversion.apache.org Subject: subversion windows passwords not stored I am using Subversion 1.8.5 under Windows 8.1 and my passwords (http repo) are not stored. I tried the default config (default options) and also explicitly setting all related options. Both did not work. I also tried setting the option manually via "--config-option" - but also without success! Further, I tried adding a server specific configuration. Options like username were applied, options like store-passwords did not make a change. During my research, I noted that only the "%APPDATA%\Subversion" directory exists (not the site-wide configuration and none of the registry keys exists). Has anyone else Windows an can confirm this? Thanks!
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
On Jan 7, 2014, at 12:01, Mojca Miklavec wrote: > On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote: > >> Which version of Apache are you using? Which Apache MPM are you using? > > Server version: Apache/2.4.7 (Unix) > > I'm not sure how to check MPM. I get > >> httpd -l > Compiled in modules: > core.c > mod_so.c > http_core.c > > but "httpd -V" as suggested on some websites doesn't work. How should > I check which MPM is being used? In what way does “httpd -V” not work? On my Mac it gives me the answer (“Server MPM: prefork”): $ httpd -V Server version: Apache/2.4.7 (Unix) Server built: Nov 26 2013 23:32:37 Server's Module Magic Number: 20120211:27 Server loaded: APR 1.4.8, APR-UTIL 1.5.2 Compiled using: APR 1.4.8, APR-UTIL 1.5.2 Architecture: 64-bit Server MPM: prefork threaded: no forked: yes (variable process count) Server compiled with -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=256 -D HTTPD_ROOT="/opt/local" -D SUEXEC_BIN="/opt/local/bin/suexec" -D DEFAULT_PIDLOG="var/run/apache2/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="etc/apache2/mime.types" -D SERVER_CONFIG_FILE="etc/apache2/httpd.conf"
subversion windows passwords not stored
I am using Subversion 1.8.5 under Windows 8.1 and my passwords (http repo) are not stored. I tried the default config (default options) and also explicitly setting all related options. Both did not work. I also tried setting the option manually via "--config-option" - but also without success! Further, I tried adding a server specific configuration. Options like username were applied, options like store-passwords did not make a change. During my research, I noted that only the "%APPDATA%\Subversion" directory exists (not the site-wide configuration and none of the registry keys exists). Has anyone else Windows an can confirm this? Thanks!
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
On Tue, Jan 7, 2014 at 7:34 PM, Philip Martin wrote: > > So you used dump/load to create a new repository and then replaced the > old repository with the new repository? If you did that while Apache > was running, without restarting Apache, then that explains the 'Corrupt > node-revision' error as you changed the data on disk. Ah, thanks a lot for explaining that. Yes, I did dump/load the old repository into a new one because I wanted to test if it would solve the problem (on client) svn: E54: Error retrieving REPORT: Connection reset by peer (on server) [dav:error] [pid 3613] [client ] Unable to deliver content. [500, #0] [dav:error] [pid 3613] [client ] Could not write data to filter. [500, #175002] which it didn't. It only added a few additional problems until I restarted Apache (I'm sorry for confusing you with those), but the initial error E54/175002 is still causing problems. > What you are left with is some sort of intermittent network problem. I > don't know what is causing that. Is there any way to debug that? Thank you very much, Mojca
Re: Reverse blame?
On 1/7/14, 10:27 AM, Benjamin Fritz wrote: > I wanted to find the revision where a certain line got removed from a > file. Taking a hint from "svn diff" and "svn merge", I tried doing an > "svn blame" with the revision range backwards. I just get an error: > > svn: E195002: Start revision must precede end revision > > I see this was discussed before: > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&viewType=browseAll&dsMessageId=105258 > > however, I don't see any official comment on it. I did try the python > script mentioned which solved my immediate problem, but I guess I'd > rather it be built-in. Can this use-case be added to blame or should I > just count on always using an external tool? Or maybe there is a > different built-in tool I could use for my purpose? It's implemented on trunk, so if you want to try out a trunk build that could help you out. Sometime soon we're going to get a 1.9.0-alpha1 out, which might mean some binary packages appear that include the support. At this point no changes have been made to the working copy format so you should be able to use the trunk/1.9 client with existing 1.8 working copies (that may change before 1.9 releases though). If you're interested in this I'd suggest you take a look. This is a great point to get feedback on new features and for us to make changes as a result.
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
Mojca Miklavec writes: > Ah, OK, I see it now in the old logs. There are no such lines in the > latest logs. > The repository is stored on a local disk. I'm not sure what about > filesystem is it that you are asking, but here are some possibly > relevant data: > >> cat format > 5 >> cat db/fs-type > fsfs >> cat db/format > 6 > layout sharded 1000 > > (and before I upgraded the repository, db/format was 4). Is that what > you were asking or do did you want to know something else? So you used dump/load to create a new repository and then replaced the old repository with the new repository? If you did that while Apache was running, without restarting Apache, then that explains the 'Corrupt node-revision' error as you changed the data on disk. What you are left with is some sort of intermittent network problem. I don't know what is causing that. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Reverse blame?
I wanted to find the revision where a certain line got removed from a file. Taking a hint from "svn diff" and "svn merge", I tried doing an "svn blame" with the revision range backwards. I just get an error: svn: E195002: Start revision must precede end revision I see this was discussed before: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&viewType=browseAll&dsMessageId=105258 however, I don't see any official comment on it. I did try the python script mentioned which solved my immediate problem, but I guess I'd rather it be built-in. Can this use-case be added to blame or should I just count on always using an external tool? Or maybe there is a different built-in tool I could use for my purpose?
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
On Tue, Jan 7, 2014 at 5:47 PM, Philip Martin wrote: > Mojca Miklavec writes: >> On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote: >>> Mojca Miklavec writes: >>> Yes, there is still a problem after restarting Apache. Even though it works for me at the moment and I tried fetching from multiple locations and servers, other users are still experiencing the same problem. Logs on the server confirm that. (Unable to deliver content. [500, #0] + Could not write data to filter. [500, #175002]) >>> >>> Does the server log always contain the error: >>> >>>svn: E160004: Corrupt node-revision '2-1.0.r137/330061' >> >> I don't see that in the server log, but I was only checking error.log >> written by Apache server, I don't know where else to look, but I can >> check if you point me in the right direction. This error is sometimes >> displayed by the "client" (either in XML in the browser or as an error >> in the command line during "svn up"), but it's not consistent and it >> often works properly. > > It would be in the Apache error log. Ah, OK, I see it now in the old logs. There are no such lines in the latest logs. > Are you saying that sometimes the client gets the E175002 error without > the 'Corrupt node-revision' part? Yes. I'm attaching full log (with timestamps and IPs removed) for a certain period of time around 4th January. There are plenty of E175002 errors without any subsequent 'Corrupt node-revision' part, including all the latest entries (not part of the attachment). > Are you saying that the client gets the 'Corrupt node-revision' error > but it is not recorded in the error log? I was wrong about that. I was only checking the latest error log where all I get is [dav:error] [pid 42289] [:29011] Unable to deliver content. [500, #0] [dav:error] [pid 42289] [:29011] Could not write data to filter. [500, #175002] But I've found those additonal errors in an old (archived) log. At the moment I'm unable to reproduce the error 'Corrupt node-revision' both on the client and in server logs, but the repository is still misbehaving. >> It sometimes works in the first attempt, fails in the second one, and >> succeeds in the third attempt again. Only seconds or minutes apart. >> >>> Is it always '2-1.0.r137/330061'? >> >> The exact revision reported as currupt depends on which subfolder I'm >> checking out. I believe it reports the last commit when files in that >> particular subfolder were modified. (I've seen this error when >> checking out two different subfolders. The number was always the same >> for the same subfolder, but different for different subfolders.) >> >> (It is a bit difficult to test because the behaviour is not consistent.) > > Which version of Apache are you using? Which Apache MPM are you using? Server version: Apache/2.4.7 (Unix) I'm not sure how to check MPM. I get > httpd -l Compiled in modules: core.c mod_so.c http_core.c but "httpd -V" as suggested on some websites doesn't work. How should I check which MPM is being used? > What sort of filesystem is used for the repository? Is it a local disk > or a network disk? The repository is stored on a local disk. I'm not sure what about filesystem is it that you are asking, but here are some possibly relevant data: > cat format 5 > cat db/fs-type fsfs > cat db/format 6 layout sharded 1000 (and before I upgraded the repository, db/format was 4). Is that what you were asking or do did you want to know something else? Mojca error.log Description: Binary data
Merging folders of different SVN repositories
Hello everyone, One of the applications of my customer in being maintained by an external vendor. The vendor delivers code to a separated SVN repository, by importing it every time as a new tag. Possibly there are more bullet-proof ways to fix it, but here is a script to repeat changes from one SVN tag to another back in the trunk of your project http://jv-ration.com/2014/01/merge-svn-directories/ With regards, Viktor Viktor Sadovnikov @ JV-ration evolution of Joint Vision Tuinluststraat 14, 2275XZ Voorburg, The Netherlands vik...@jv-ration.com | http://jv-ration.com | +31 6 2466 0736
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
Mojca Miklavec writes: > On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote: >> Mojca Miklavec writes: >> >>> Yes, there is still a problem after restarting Apache. Even though it >>> works for me at the moment and I tried fetching from multiple >>> locations and servers, other users are still experiencing the same >>> problem. Logs on the server confirm that. (Unable to deliver content. >>> [500, #0] + Could not write data to filter. [500, #175002]) >> >> Does the server log always contain the error: >> >>svn: E160004: Corrupt node-revision '2-1.0.r137/330061' > > I don't see that in the server log, but I was only checking error.log > written by Apache server, I don't know where else to look, but I can > check if you point me in the right direction. This error is sometimes > displayed by the "client" (either in XML in the browser or as an error > in the command line during "svn up"), but it's not consistent and it > often works properly. It would be in the Apache error log. Are you saying that sometimes the client gets the E175002 error without the 'Corrupt node-revision' part? Are you saying that the client gets the 'Corrupt node-revision' error but it is not recorded in the error log? > It sometimes works in the first attempt, fails in the second one, and > succeeds in the third attempt again. Only seconds or minutes apart. > >> Is it always '2-1.0.r137/330061'? > > The exact revision reported as currupt depends on which subfolder I'm > checking out. I believe it reports the last commit when files in that > particular subfolder were modified. (I've seen this error when > checking out two different subfolders. The number was always the same > for the same subfolder, but different for different subfolders.) > > (It is a bit difficult to test because the behaviour is not consistent.) Which version of Apache are you using? Which Apache MPM are you using? What sort of filesystem is used for the repository? Is it a local disk or a network disk? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
On Tue, Jan 7, 2014 at 5:18 PM, Philip Martin wrote: > Mojca Miklavec writes: > >> Yes, there is still a problem after restarting Apache. Even though it >> works for me at the moment and I tried fetching from multiple >> locations and servers, other users are still experiencing the same >> problem. Logs on the server confirm that. (Unable to deliver content. >> [500, #0] + Could not write data to filter. [500, #175002]) > > Does the server log always contain the error: > >svn: E160004: Corrupt node-revision '2-1.0.r137/330061' I don't see that in the server log, but I was only checking error.log written by Apache server, I don't know where else to look, but I can check if you point me in the right direction. This error is sometimes displayed by the "client" (either in XML in the browser or as an error in the command line during "svn up"), but it's not consistent and it often works properly. It sometimes works in the first attempt, fails in the second one, and succeeds in the third attempt again. Only seconds or minutes apart. > Is it always '2-1.0.r137/330061'? The exact revision reported as currupt depends on which subfolder I'm checking out. I believe it reports the last commit when files in that particular subfolder were modified. (I've seen this error when checking out two different subfolders. The number was always the same for the same subfolder, but different for different subfolders.) (It is a bit difficult to test because the behaviour is not consistent.) Mojca
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
Mojca Miklavec writes: > Yes, there is still a problem after restarting Apache. Even though it > works for me at the moment and I tried fetching from multiple > locations and servers, other users are still experiencing the same > problem. Logs on the server confirm that. (Unable to deliver content. > [500, #0] + Could not write data to filter. [500, #175002]) Does the server log always contain the error: svn: E160004: Corrupt node-revision '2-1.0.r137/330061' Is it always '2-1.0.r137/330061'? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
On Tue, Jan 7, 2014 at 12:41 PM, Philip Martin wrote: > Mojca Miklavec writes: > >> We have a server running Fedora which has recently been upgraded to >> version 20 and it's now running >> svn, version 1.8.5 (r1542147) >> >> I have a bunch of repositories served over http protocol with public >> read access and limited commit access. >> >> Shortly after the upgrade a weird behaviour has been noticed. Running >> "svn up" on the top level dir worked ok for me, but running >> svn co http://svn.myserver.net/myrepo/dirA >> fails with >> >> AdirA/subdir1 >> AdirA/subdir2 >> AdirA/subdir3 >> AdirA/subdir4 >> svn: E54: Error retrieving REPORT: Connection reset by peer >> >> The directory "dirA" contains one more file FILE.txt. Checking out any >> individual "subdirN" works and the browser is able to display the >> contents of dirA. >> >> Trying to click on FILE.txt in the browser sometimes works (it >> currently does) and sometimes shows an XML (like a few minutes ago, >> but I'm unable to get it now), saying something similar to the error I >> get in console***: >> >> svn: E175002: Unable to connect to a repository at URL >> 'svn.myserver.net/myrepo/dirA' >> svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on >> '/myrepo/dirA' >> >> svn: E160004: Additional errors: >> svn: E160004: Corrupt node-revision '2-1.0.r137/330061' >> >> (*** To be precise: this is the error I get after upgrading the >> repository to the latest version of SVN, I didn't try to get to this >> error before upgrading.) >> >> The error.log in apache says just: >> >> [] [dav:error] [pid 3613] [client ] Unable to deliver >> content. [500, #0] >> [] [dav:error] [pid 3613] [client ] Could not write >> data to filter. [500, #175002] >> >> I first tried if upgrading the repository would help in any way, so I did >> svnadmin dump oldrepo | svnadmin load newrepo >> and checking the relevant revision r137 cited in the error all I see >> is the following (nothing unusual): >> >> --- Committed revision 136 >>> >> >> <<< Started new transaction, based on original revision 137 >> * editing path : dirA/FILE.txt ... done. >> * Dumped revision 137. >> * editing path : dirA/subdir1/somefile ... done. >> >> --- Committed revision 137 >>> >> >> Checking out the same repository via http on the machine where the >> repository itself is located works fine. >> >> I'm using the same version of SVN (1.8.5) on Mac, but other svn >> clients on other OSes have problems as well. >> >> I tried checking the repository health with >> svnadmin verify /path/to/myrepo >> and all revisions passed except for some weird error inbetween (the >> file rev-prop-atomics.mutex is actually missing, but it isn't present >> in any other repository either): >> >> * Verifying repository metadata ... >> * Verifying metadata at revision 1 ... >> ... >> * Verifying metadata at revision 155 ... >> svnadmin: E160052: Revprop caching for '/path/to/myrepo/db' disabled >> because SHM infrastructure for revprop caching failed to initialize. >> svnadmin: E13: Can't open file >> '/path/to/myrepo/db/rev-prop-atomics.mutex': Permission denied >> * Verified revision 0. >> ... >> * Verified revision 160. >> >> >> I would appreciate any help or debugging hints. If necessary I can >> share the repository URL (but I would prefer to share it off-list to >> anyone interested in debugging). I can also try to debug myself, but I >> need some instructions telling me what to check. I didn't manage to >> find anything useful by googling the errors other than figuring out >> that the error was part of the code to fix a memory leak >> (http://svn.haxx.se/dev/archive-2009-08/0274.shtml). > > I've not seen E54 before but it is EXFULL which is some sort of > network error. I suppose the corruption causes some sort of output > problem. > > E13 is EACCES so you are running verify without write access to the > repository. That seems like a perfectly reasonable thing to do so we > should probably make the warning less intimidating. > > It's very odd that Apache is reporting corruption but both the dump/load > and verify work without problem. Is the problem reproducible if you > restart Apache? Yes, there is still a problem after restarting Apache. Even though it works for me at the moment and I tried fetching from multiple locations and servers, other users are still experiencing the same problem. Logs on the server confirm that. (Unable to deliver content. [500, #0] + Could not write data to filter. [500, #175002]) Mojca
Re: Seeking help for "E000054: Error retrieving REPORT: Connection reset by peer"
Mojca Miklavec writes: > We have a server running Fedora which has recently been upgraded to > version 20 and it's now running > svn, version 1.8.5 (r1542147) > > I have a bunch of repositories served over http protocol with public > read access and limited commit access. > > Shortly after the upgrade a weird behaviour has been noticed. Running > "svn up" on the top level dir worked ok for me, but running > svn co http://svn.myserver.net/myrepo/dirA > fails with > > AdirA/subdir1 > AdirA/subdir2 > AdirA/subdir3 > AdirA/subdir4 > svn: E54: Error retrieving REPORT: Connection reset by peer > > The directory "dirA" contains one more file FILE.txt. Checking out any > individual "subdirN" works and the browser is able to display the > contents of dirA. > > Trying to click on FILE.txt in the browser sometimes works (it > currently does) and sometimes shows an XML (like a few minutes ago, > but I'm unable to get it now), saying something similar to the error I > get in console***: > > svn: E175002: Unable to connect to a repository at URL > 'svn.myserver.net/myrepo/dirA' > svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on > '/myrepo/dirA' > > svn: E160004: Additional errors: > svn: E160004: Corrupt node-revision '2-1.0.r137/330061' > > (*** To be precise: this is the error I get after upgrading the > repository to the latest version of SVN, I didn't try to get to this > error before upgrading.) > > The error.log in apache says just: > > [] [dav:error] [pid 3613] [client ] Unable to deliver > content. [500, #0] > [] [dav:error] [pid 3613] [client ] Could not write > data to filter. [500, #175002] > > I first tried if upgrading the repository would help in any way, so I did > svnadmin dump oldrepo | svnadmin load newrepo > and checking the relevant revision r137 cited in the error all I see > is the following (nothing unusual): > > --- Committed revision 136 >>> > > <<< Started new transaction, based on original revision 137 > * editing path : dirA/FILE.txt ... done. > * Dumped revision 137. > * editing path : dirA/subdir1/somefile ... done. > > --- Committed revision 137 >>> > > Checking out the same repository via http on the machine where the > repository itself is located works fine. > > I'm using the same version of SVN (1.8.5) on Mac, but other svn > clients on other OSes have problems as well. > > I tried checking the repository health with > svnadmin verify /path/to/myrepo > and all revisions passed except for some weird error inbetween (the > file rev-prop-atomics.mutex is actually missing, but it isn't present > in any other repository either): > > * Verifying repository metadata ... > * Verifying metadata at revision 1 ... > ... > * Verifying metadata at revision 155 ... > svnadmin: E160052: Revprop caching for '/path/to/myrepo/db' disabled > because SHM infrastructure for revprop caching failed to initialize. > svnadmin: E13: Can't open file > '/path/to/myrepo/db/rev-prop-atomics.mutex': Permission denied > * Verified revision 0. > ... > * Verified revision 160. > > > I would appreciate any help or debugging hints. If necessary I can > share the repository URL (but I would prefer to share it off-list to > anyone interested in debugging). I can also try to debug myself, but I > need some instructions telling me what to check. I didn't manage to > find anything useful by googling the errors other than figuring out > that the error was part of the code to fix a memory leak > (http://svn.haxx.se/dev/archive-2009-08/0274.shtml). I've not seen E54 before but it is EXFULL which is some sort of network error. I suppose the corruption causes some sort of output problem. E13 is EACCES so you are running verify without write access to the repository. That seems like a perfectly reasonable thing to do so we should probably make the warning less intimidating. It's very odd that Apache is reporting corruption but both the dump/load and verify work without problem. Is the problem reproducible if you restart Apache? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Hello Bert, First of all, happy New Year. I hope you had a nice time over the holidays. Our Subversion 1.5.5 is integrated with TeamForge 5.2. TeamForge is responsible for all configuration. As we have a support contract with CollabNet, the developer of TeamForge, I have already raised the issue because of the logs you asked for (I was not sure if they contain sensitive information) and send them the copy of the session and the respective logs. I was able to reproduce the issue by SlikSVN 1.8.5, as well by CollabNet subversion 1.8.5.1 client. I am not sure if you use the same libraries as CollabNet (or even work with them) but I think so. If this is true and considering that they already are after the issue I propose to wait for their feedback - or eventually for their fix, which may influence SlikSVN and TortoiseSVN. I will keep you posted. Kind regards Jan -Original Message- From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Montag, 23. Dezember 2013 15:07 To: JANIKOVIC Jan; 'Geoff Field'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? > -Original Message- > From: JANIKOVIC Jan [mailto:jan.janiko...@power.alstom.com] > Sent: maandag 23 december 2013 12:58 > To: Bert Huijben; 'Geoff Field'; users@subversion.apache.org > Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the > tracker already? > > Hello Bert, > > Would these reproduction steps help? If there is a way how to get a > log file, > or any other way to help fixing this issue, please let me know: > > Server installation: RHEL 4, Subversion svn, version 1.5.5 Computer > installation: TortoiseSVN 1.8.4, serf 1.3.2, computer restarted after > installation I'm developing on Windows, so this makes it very hard to replicate this problem for me... Eventually your old report made it possible to replicate the HEAD problem for me on Windows, which made me debug serf and Subversion. And even then I would setup my repository using a pretty standard configuration using a normal password backend; the default number of requests, etc. etc. Your older reports noted that you didn't use a plain text password backend, etc. That is 100% essential information to get things reproduced for anybody. Requiring a specific pretty old, platform to reproduce anything is making it less likely that anybody can reproduce it. Did you try your setup (=config files) on a setup that is actively supported by any of the commercial vendors? If you can that would really help. > 1. Repository updated How do you update a repository? Let's assume $ svnadmin create REPOSITORY And hooking that to a url http://my-server/svn/repos $ svn import greekfiles http://my-server/svn/repos/ -m "" Adding greekfiles\A Adding greekfiles\A\B Adding greekfiles\A\B\E Adding greekfiles\A\B\E\alpha Adding greekfiles\A\B\E\beta Adding greekfiles\A\B\F Adding greekfiles\A\B\lambda Adding greekfiles\A\C Adding greekfiles\A\D Adding greekfiles\A\D\G Adding greekfiles\A\D\G\pi Adding greekfiles\A\D\G\rho Adding greekfiles\A\D\G\tau Adding greekfiles\A\D\H Adding greekfiles\A\D\H\chi Adding greekfiles\A\D\H\omega Adding greekfiles\A\D\H\psi Adding greekfiles\A\D\gamma Adding greekfiles\A\mu Adding greekfiles\iota Committed revision 1. So now we have a repository... (See our FAQ and 'HACKING' for some tricks to setup test environments) > 2. File "new.txt" with arbitrary content copied to the repository > folder on the > computer Copying files to a repository directory is never recommended. Let's assume you are talking about a working copy $ svn co http://my-server/svn/repos wc $ touch wc/new.txt $ svn add wc/new.txt > 3. Right-mouse click on the new file: TortoiseSVN->Add 4. Right-mouse > click on the new file: SVN Commit 5. Press OK on the Commit dialog > that appears On this list we +- assume that you use 'svn', so let's assume that you did $ svn commit -m "Message" wc Adding wc\new.txt Committed revision 2. > 6. Form "Authentication" appears with following text: > Authorization Realm > > Request username and password > Username: [textbox] > Password: [textbox] > [checkbox] Save Authentication This eventually documents that you did setup authentication on your repository. We should add that information to step 1. > > 7. After third attempt to enter the login commit fails with following message: > > > Error: Commit failed (details follow): > Error: No more credentials or we tried too many times. > Error: Authentication failed > Error: Additional errors: > Error: Error running context: The requested authentication type(s) are > not supported > In your origi
