Re: Permissions need for deletion
On 31 August 2016 at 14:54, Vacelet, Manuel <manuel.vace...@enalean.com> wrote: > On Wed, Aug 31, 2016 at 12:37 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> On 31 August 2016 at 13:28, Vacelet, Manuel <manuel.vace...@enalean.com> >> wrote: >> > On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov <i...@visualsvn.com> >> > wrote: >> >> >> >> >> >> > - Why this behaviour changed between 1.6 and newer ? >> >> It was bug before Subversion 1.7.9. The problem was that client tried >> >> to read some information from repository root when performing remove >> >> folder. See SVN-4332 for more details [1] >> >> >> >> [1] https://issues.apache.org/jira/browse/SVN-4332 >> >> >> > >> > I did read that but in my tests, when server is 1.6, whatever version of >> > client (1.6, 1.7, 1.8, 1.9), cannot remove. >> > >> > When server is 1.8, behaviour change depending on client version so it >> > might >> > be related to this issue (even if in all cases, the user has access to >> > the >> > root). >> > >> It's could be related to HTTPv2 protocol introduced in Subversion 1.7. >> Could you provide requests log with svn server 1.6? >> >> [1] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2 >> > > Here we go, on client side, svn, version 1.9.3 (r1718519) > > Server is svn, version 1.6.11 (r934486) > 172.17.42.1 - - [31/Aug/2016:11:52:37 +] "OPTIONS /svntest/fakerepo/tags > HTTP/1.1" 401 501 > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +] "OPTIONS > /svntest/fakerepo/tags HTTP/1.1" 200 196 > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +] "OPTIONS > /svntest/fakerepo/tags HTTP/1.1" 200 97 > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +] "PROPFIND > /svntest/fakerepo/tags HTTP/1.1" 207 700 > 172.17.42.1 - alice [31/Aug/2016:11:52:37 +] "PROPFIND > /svntest/fakerepo/tags HTTP/1.1" 207 325 > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +] "MKACTIVITY > /svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9 HTTP/1.1" > 201 337 > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +] "PROPFIND /svntest/fakerepo > HTTP/1.1" 207 400 > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +] "CHECKOUT > /svntest/fakerepo/!svn/vcc/default HTTP/1.1" 201 352 > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +] "PROPPATCH > /svntest/fakerepo/!svn/wbl/8267278f-ed0c-42db-a6c8-65f010a954c9/15 HTTP/1.1" > 207 469 > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +] "CHECKOUT > /svntest/fakerepo/!svn/ver/15 HTTP/1.1" 403 330 ^^^ Here is the problem. Subversion tries to CHECKOUT (DAV HTTP method) parent of resource when using HTTPv1 protocol, but it should not. I was able to reproduce this problem locally. As far I see we don't have test for this case. > 172.17.42.1 - alice [31/Aug/2016:11:52:40 +] "DELETE > /svntest/fakerepo/!svn/act/8267278f-ed0c-42db-a6c8-65f010a954c9 HTTP/1.1" > 204 - > > Server is svn, version 1.8.16 (r1740329): > 172.17.42.1 - - [31/Aug/2016:11:43:53 +] "OPTIONS /svntest/fakerepo > HTTP/1.1" 401 501 > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +] "OPTIONS /svntest/fakerepo > HTTP/1.1" 200 196 > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +] "OPTIONS /svntest/fakerepo > HTTP/1.1" 200 97 > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +] "POST > /svntest/fakerepo/!svn/me HTTP/1.1" 201 - > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +] "DELETE > /svntest/fakerepo/!svn/txr/13-g/tags HTTP/1.1" 204 - > 172.17.42.1 - alice [31/Aug/2016:11:43:53 +] "MERGE /svntest/fakerepo > HTTP/1.1" 200 756 > As you see Subversion perform DELETE directly, without CHECKOUT when using HTTPv2 protocol. That's expected behavior. -- Ivan Zhakov
Re: Permissions need for deletion
On 31 August 2016 at 13:28, Vacelet, Manuel <manuel.vace...@enalean.com> wrote: > On Wed, Aug 31, 2016 at 12:19 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> >> > - Why this behaviour changed between 1.6 and newer ? >> It was bug before Subversion 1.7.9. The problem was that client tried >> to read some information from repository root when performing remove >> folder. See SVN-4332 for more details [1] >> >> [1] https://issues.apache.org/jira/browse/SVN-4332 >> > > I did read that but in my tests, when server is 1.6, whatever version of > client (1.6, 1.7, 1.8, 1.9), cannot remove. > > When server is 1.8, behaviour change depending on client version so it might > be related to this issue (even if in all cases, the user has access to the > root). > It's could be related to HTTPv2 protocol introduced in Subversion 1.7. Could you provide requests log with svn server 1.6? [1] https://subversion.apache.org/docs/release-notes/1.7.html#httpv2 >> But according to provided authz file 'alice' has read access to >> repository root, so it may be different issue. Anyway, your authz file >> allows 'alice' to remove /tags. > > OK thanks for the info, do you know if it's documented / specified somewhere > ? > I tried to get this info from > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html > but those rules are not described. > I'm not aware about documentation, but it seems natural that user only need write to resource to remove it. -- Ivan Zhakov
Re: Permissions need for deletion
On 31 August 2016 at 13:04, Vacelet, Manuel <manuel.vace...@enalean.com> wrote: > On Thu, Aug 25, 2016 at 11:29 AM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> On 25 August 2016 at 12:19, Vacelet, Manuel <manuel.vace...@enalean.com> >> wrote: [...] > > Ivan, > Hi Manuel, > I don't think it the same issue as in my case, the users always have access > to repository root. > Moreover I don't have a consistent behaviour with clients that are newer > than 1.7.9 (tested with clients 1.8 & 1.9). > > I don't know if it's a bug, actually my issue is: > - What is the expected behaviour (what are the rights needed to delete a > folder, write on the folder or write on its parent) ? To remove folder user only need write access to the folders and all it's children > - Why this behaviour changed between 1.6 and newer ? It was bug before Subversion 1.7.9. The problem was that client tried to read some information from repository root when performing remove folder. See SVN-4332 for more details [1] [1] https://issues.apache.org/jira/browse/SVN-4332 But according to provided authz file 'alice' has read access to repository root, so it may be different issue. Anyway, your authz file allows 'alice' to remove /tags. -- Ivan Zhakov
Re: Permissions need for deletion
On 25 August 2016 at 12:30, Stefan Hett <ste...@egosoft.com> wrote: > On 8/25/2016 11:13 AM, Ivan Zhakov wrote: >> >> On 25 August 2016 at 11:50, Vacelet, Manuel <manuel.vace...@enalean.com> >> wrote: >>> >>> On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel >>> <manuel.vace...@enalean.com> wrote: >>>> >>>> oops I hit shift+enter :/ >>>> see my message below >>>> >>>> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel >>>> <manuel.vace...@enalean.com> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I got a machine that was bumped from 1.6.x (centos6 default) to 1.8.16 >>>>> (thanks wandisco!). >>>>> I identified a change of behaviour but failed to find an explanation in >>>>> book or change log. >>>>> >>>>> Here we go, given a SVNAccessFile like: >>>> >>>> >>>> ->8- >>>> [groups] >>>> members = alice >>>> admin = bob >>>> >>>> [/] >>>> * = >>>> @members = r >>>> @admin = rw >>>> >>>> [/tags] >>>> @members = rw >>>> -8<- >>>> >>>> WIth svn 1.6, as alice, I cannot rm /tags >>>> Whereas with svn 1.8 I now can. >>>> >>>> Is this detailed somewhere ? >>> >>> >>> Fun fact: the behaviour change also depending on the version of svn >>> client >>> used. >>> For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 & svn >>> 1.9 >>> client but not with svn 1.6. >>> I failed to find in 1.7 release note something that explains this change. >>> >> It was bug in Subversion 1.7 that remove operation requires access to >> repository root: >> SVN-4219: svn delete fails with "403 Forbidden" if root is not readable >> [1] >> >> This problem was fixed in Subversion 1.8. It's not server-side change. >> It was client problem accessing repository root, while it's not >> needed. >> >> [1] https://issues.apache.org/jira/browse/SVN-4219 > > According to SVN-4219 the issue was present in 1.7 and also fixed in 1.7, or > is the JIRA issue record wrong in this regards? > Also I take it that with Manuel's report here, the issue was not only > present in 1.7 but also existed on 1.6. Otherwise I think I'm missing > something. > The SVN-4219 is duplicate issue for SVN-4332. -- Ivan Zhakov
Re: Permissions need for deletion
On 25 August 2016 at 12:19, Vacelet, Manuel <manuel.vace...@enalean.com> wrote: > On Thu, Aug 25, 2016 at 11:13 AM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> On 25 August 2016 at 11:50, Vacelet, Manuel <manuel.vace...@enalean.com> >> wrote: >> > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel >> > <manuel.vace...@enalean.com> wrote: >> >> >> >> oops I hit shift+enter :/ >> >> see my message below >> >> >> >> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel >> >> <manuel.vace...@enalean.com> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> I got a machine that was bumped from 1.6.x (centos6 default) to 1.8.16 >> >>> (thanks wandisco!). >> >>> I identified a change of behaviour but failed to find an explanation >> >>> in >> >>> book or change log. >> >>> >> >>> Here we go, given a SVNAccessFile like: >> >> >> >> >> >> ->8- >> >> [groups] >> >> members = alice >> >> admin = bob >> >> >> >> [/] >> >> * = >> >> @members = r >> >> @admin = rw >> >> >> >> [/tags] >> >> @members = rw >> >> -8<- >> >> >> >> WIth svn 1.6, as alice, I cannot rm /tags >> >> Whereas with svn 1.8 I now can. >> >> >> >> Is this detailed somewhere ? >> > >> > >> > Fun fact: the behaviour change also depending on the version of svn >> > client >> > used. >> > For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 & svn >> > 1.9 >> > client but not with svn 1.6. >> > I failed to find in 1.7 release note something that explains this >> > change. >> > >> It was bug in Subversion 1.7 that remove operation requires access to >> repository root: >> SVN-4219: svn delete fails with "403 Forbidden" if root is not readable >> [1] >> >> This problem was fixed in Subversion 1.8. It's not server-side change. >> It was client problem accessing repository root, while it's not >> needed. >> >> [1] https://issues.apache.org/jira/browse/SVN-4219 >> > > Thanks for your reply, but according to my tests, the behaviour is > consistent with clients >1.7: > server 1.8: > * client 1.6: cannot rm > * client >1.7: can rm > > server 1.6: > * client >1.6: cannot rm > > Moreove, alice does have access to root in this case (but only in read). > You are right. The issue was fixed in Subversion 1.7.9 https://issues.apache.org/jira/browse/SVN-4332 (I've checked wrong duplicated issue before) -- Ivan Zhakov
Re: Permissions need for deletion
On 25 August 2016 at 11:50, Vacelet, Manuel <manuel.vace...@enalean.com> wrote: > On Wed, Aug 24, 2016 at 5:46 PM, Vacelet, Manuel > <manuel.vace...@enalean.com> wrote: >> >> oops I hit shift+enter :/ >> see my message below >> >> On Wed, Aug 24, 2016 at 5:44 PM, Vacelet, Manuel >> <manuel.vace...@enalean.com> wrote: >>> >>> Hi all, >>> >>> I got a machine that was bumped from 1.6.x (centos6 default) to 1.8.16 >>> (thanks wandisco!). >>> I identified a change of behaviour but failed to find an explanation in >>> book or change log. >>> >>> Here we go, given a SVNAccessFile like: >> >> >> ->8- >> [groups] >> members = alice >> admin = bob >> >> [/] >> * = >> @members = r >> @admin = rw >> >> [/tags] >> @members = rw >> -8<- >> >> WIth svn 1.6, as alice, I cannot rm /tags >> Whereas with svn 1.8 I now can. >> >> Is this detailed somewhere ? > > > Fun fact: the behaviour change also depending on the version of svn client > used. > For a given svn 1.8 server, I can delete /tags with svn 1.7, 1.8 & svn 1.9 > client but not with svn 1.6. > I failed to find in 1.7 release note something that explains this change. > It was bug in Subversion 1.7 that remove operation requires access to repository root: SVN-4219: svn delete fails with "403 Forbidden" if root is not readable [1] This problem was fixed in Subversion 1.8. It's not server-side change. It was client problem accessing repository root, while it's not needed. [1] https://issues.apache.org/jira/browse/SVN-4219 -- Ivan Zhakov
Re: svn log out of memory
On 11 August 2016 at 17:30, Ivan Zhakov <i...@visualsvn.com> wrote: > On 27 July 2016 at 14:09, Ivan Zhakov <i...@visualsvn.com> wrote: >> 2016-07-26 16:10 GMT+03:00 Niemann, Hartmut <hartmut.niem...@siemens.com>: >>> >>> Hello! >>> The command line client of Tortoise Subversion: >>> >>> D:\>svn --version >>> svn, version 1.9.4 (r1740329) >>> >>>compiled Apr 24 2016, 15:40:35 on x86-microsoft-windows >>> >>> runs out of memory on a very long commit message: >>> >>> D:\>svn log ZD.itm -r3340 >>> r3340 | e09dueu0 | 2016-02-19 13:31:58 +0100 (Fr, 19 Feb 2016) | 2571 lines >>> >>> svn: E720008: Write error: Für diesen Befehl ist nicht genügend Speicher >>> verfügbar. >>> >>> The XML output works fine: >>> >>> D:\>svn log ZD.itm -r3340 --xml >>> >>> Why does svn log fail on the text output but handles the same amount if it >>> is XML? >>> >> >> The actual error is: >> OS 8: Not enough storage is available to process this command. >> >> Could you try run 'svn log' with redirected output, i.e.: >> svn log ZD.itm -r3340 >test.txt >> > Looks like problem similar to SVN-1789: > https://issues.apache.org/jira/browse/SVN-1789 > I was able to reproduce this problem with huge svn:log on Windows Server 2008 R2 (Win7), but it doesn't reproduce on Windows Server 2012 R2 and Windows 10. Most likely this 32KB WriteFile to console limitation was fixed as part of conhost.exe fixes in Windows 8 and later. -- Ivan Zhakov
Re: svn log out of memory
On 27 July 2016 at 14:09, Ivan Zhakov <i...@visualsvn.com> wrote: > 2016-07-26 16:10 GMT+03:00 Niemann, Hartmut <hartmut.niem...@siemens.com>: >> >> Hello! >> The command line client of Tortoise Subversion: >> >> D:\>svn --version >> svn, version 1.9.4 (r1740329) >> >>compiled Apr 24 2016, 15:40:35 on x86-microsoft-windows >> >> runs out of memory on a very long commit message: >> >> D:\>svn log ZD.itm -r3340 >> r3340 | e09dueu0 | 2016-02-19 13:31:58 +0100 (Fr, 19 Feb 2016) | 2571 lines >> >> svn: E720008: Write error: Für diesen Befehl ist nicht genügend Speicher >> verfügbar. >> >> The XML output works fine: >> >> D:\>svn log ZD.itm -r3340 --xml >> >> Why does svn log fail on the text output but handles the same amount if it >> is XML? >> > > The actual error is: > OS 8: Not enough storage is available to process this command. > > Could you try run 'svn log' with redirected output, i.e.: > svn log ZD.itm -r3340 >test.txt > Looks like problem similar to SVN-1789: https://issues.apache.org/jira/browse/SVN-1789 -- Ivan Zhakov
Re: differences in dump/load/dump cycle
On 2 August 2016 at 14:01, Stefan Hett <ste...@egosoft.com> wrote: > On 7/31/2016 11:54 PM, Johan Corveleyn wrote: >> >> On Sun, Jul 31, 2016 at 5:55 PM, Stefan <luke1...@posteo.de> wrote: >>> >>> Hi, >>> >>> I went through a long overdue dump/load cycle of our main repository and >>> am wondering atm about a difference I see when comparing the dump of the >>> repository with the original dump. >>> >>> There are a few (at a guess around 20-50) differences of the following >>> structure (using fc [olddump] [newdump] on Windows): >>> >>> * svn.dump >>> >>> Node-path: XRebirth/tags/XR v3.53 RC2 (final)/src/SDKs/DX9SDK >>> Node-kind: dir >>> Node-action: change >>> >>> >>> Revision-number: 193958 >>> * SVN_NEW.DMP >>> >>> Revision-number: 193958 >>> * >>> >>> >>> svn.dump was generated using svnadmin 1.8.15 (32-bit). >>> >>> The dump was then loaded in a new clean repository using svnadmin 1.8.16 >>> (64-bit). svn_new.dmp was then written using svnadmin 1.8.16 (64-bit) as >>> well. >>> >>> The original repository was created using SVN 1.7. At some point in the >>> past (around 2 years ago) the server was upgraded to SVN 1.8 but the >>> repository was still kept at fsfs format 5. Around a year later the >>> repository was upgraded to SVN 1.8 (fsfs format 6). >>> >>> For the new repository fsfs.conf was modified to enable directory and >>> property deltification. >>> >>> For the DX9SDK directory (which is reported being different in both >>> dumps in some revisions) this was originally using externals and at some >>> point we switched to a direct copy of the folder (not sure whether >>> that's relevant though). >>> >>> Is this difference expected? I remember (and Bert mentioned it too) that >>> there were some cases for different handling of noop-changes. Is that >>> what explains the difference I see here? If so, I take it that's >>> expected and does not result in any difference between the repository >>> states, or does it? JCorvel, would you have an idea? >>> >> It's possible that this is a benign change, with no visible effects. >> I'm not sure. >> >> The problem I ran into with dump was a new bug in 1.9.0 (fixed in >> 1.9.3 I think). It was with no-op changes to files, not directories. >> This was IMO definitely a bug, because the effect was visible in the >> new repository (namely, if you ran 'svn log somepath', where somepath >> was a file which had such a no-op change (not possible to create with >> the standard svn client btw, but possible with other tools or from a >> cvs2svn conversion) in revision R, then revision R would not be listed >> as part of somepath's history). It's unclear to me if you can see a >> similar loss of "changed-path / history" association. >> >> In my case the change in the dumpfile was a bit different: the >> Node-path / Node-kind / Node-action lines were still there, but the >> Text-content lines were gone (if you dumped again from the new >> repository, the entire block with Node-path etc would be gone). See >> http://svn.haxx.se/dev/archive-2015-09/0269.shtml for the entire >> (long) discussion, which lead to the bugfix for 1.9.3. > > Ah right. Now i recall. Thanks for digging that up. So unless I observe any > issues, I take it that the change I observed is just a benign one. > Just for the records SVN-4598 [1]: No-op changes no longer dumped by 'svnadmin dump' in 1.9 [1] https://issues.apache.org/jira/browse/SVN-4598 -- Ivan Zhakov
Re: svn log out of memory
2016-07-26 16:10 GMT+03:00 Niemann, Hartmut <hartmut.niem...@siemens.com>: > > Hello! > The command line client of Tortoise Subversion: > > D:\>svn --version > svn, version 1.9.4 (r1740329) > >compiled Apr 24 2016, 15:40:35 on x86-microsoft-windows > > runs out of memory on a very long commit message: > > D:\>svn log ZD.itm -r3340 > r3340 | e09dueu0 | 2016-02-19 13:31:58 +0100 (Fr, 19 Feb 2016) | 2571 lines > > svn: E720008: Write error: Für diesen Befehl ist nicht genügend Speicher > verfügbar. > > The XML output works fine: > > D:\>svn log ZD.itm -r3340 --xml > > Why does svn log fail on the text output but handles the same amount if it is > XML? > The actual error is: OS 8: Not enough storage is available to process this command. Could you try run 'svn log' with redirected output, i.e.: svn log ZD.itm -r3340 >test.txt -- Ivan Zhakov
Re: Problem with locking multiple files.
[please use plain-text formatting as documented in Community Guide [1]] https://subversion.apache.org/docs/community-guide/mailing-lists.html#encodings On 9 May 2016 at 12:05, Stefan Hett <ste...@egosoft.com> wrote: >> On 5/9/2016 10:55 AM, Stefan Hett wrote: >>> On 5/9/2016 10:09 AM, Ivan Zhakov wrote: [...] >>> Could you please provide reproduction script using command line >>> client? As far I understand the problem in 'Java-SSL-Tunnel', not in >>> Subversion itself. >> I'll forward that to the user on the TSVN list, since I don't have any >> environment >> at hand here to reproduce the described issue. > > Seems like I'm not fully awake yet... As far as I understood the issue, > there's > no way to reproduce the scenario just using the command line client, since > that doesn't allow to lock multiple files over different paths (aka: there's > no > recursive-flag for svn lock). > 'svn lock' accepts multiple targets: $ svn lock a b c 'a' locked by user 'ivan'. 'b' locked by user 'ivan'. 'c' locked by user 'ivan'. > The only way to reproduce the problem atm seems to be using some other > client. In this particular case the issue is reported to be reproducible using > TSVN 1.9.4 (which according to Stefan Küng uses the SVN API directly > for the lock/unlock feature --- aka: I assume he's calling svn_ra_lock() by > passing multiple path_revs - didn't check that, so take it with care). > > Do you have a lead for me how to get any further information from the user > which would help to investigate the issue? - RA layer is being used? - Server-side Subversion version? But most likely 'Java-SSL-Tunnel' acts as a 'busted proxy' and doesn't handle HTTP pipelining properly. I assume users uses http:// protocol to access the server. Switching to https:// may help in this case. -- Ivan Zhakov
Re: Problem with locking multiple files.
On 6 May 2016 at 14:37, Stefan Hett <ste...@egosoft.com> wrote: > Hi, > > this is in reference to a user reported problem on the TSVN mailing list [1] > > The user is having an issue with using TSVN 1.9.4 over a Java-SSL-Tunnel > when trying to lock hundreds or thousands of files. The same operation works > without problems when: > - using TSVN 1.8.12 or > - using the SVN command line client (1.8 or 1.9) > - disabling the Java-SSL-Tunnel > > I've been pointed to issue #4557 [2] by stsp. I'm not 100% certain whether > this really is the particular problem the user runs into but even if it > wouldn't be the case here, the underlying issue of #4557 might be worth > changing/fixing in 1.9 as well. > > The reasoning from a users / downstream-developer's point of view would be > that the new way could fail in a particular environment which the old (aka: > 1.8) way would work just fine. So if I as a developer make use of the new > functionality, it would look like a regression to my userbase of my tool. > > Does that make sense to you? Should I create a new JIRA issue for that case > (in contrast to SVN-4557 that would differ in that the effected version > would be 1.9.x - not 1.8.x - aka: no regression)? > Could you please provide reproduction script using command line client? As far I understand the problem in 'Java-SSL-Tunnel', not in Subversion itself. -- Ivan Zhakov
Re: svnversion output changed when redirecting the output. Why?
On 10 February 2016 at 18:09, Steenveld, Andre <a.h.m.steenv...@marin.nl> wrote: > > Hi, > > I’m working with svn (via TortoiseSVN) versions 1.7, 1.8 and 1.9 and due to > external factors I cannot bring it up to the same version. > > Also, I’m using svn via the TortoiseSVN package but I believe that my > question is related to svn and not to TortoseSVN, please correct me it this > is not the case. > > I use the svnversion command to keep track of versions in my sandboxes. For > this I redirect the output from svnversion to a file and use that file in > other parts. > > For versions 1.7 and 1.8 the command line output from svnversion is identical > to the redirected output. But for version 1.9 it is not and there is no > command line option to get it to the `old style’ output. > > Here is an example for 1.8 > > C:\…> svnversion . > 22923:22924M > > C:\...>svnversion . > output.txt > C:\...>type output.txt > 22923:22924M > > And here is the same example but now for 1.9 > > C:\…> svnversion . > > 22923:22924M > > C:\...>svnversion . > output.txt > C:\...>type output.txt > > M > > 22923:22924 > > Note that if the sandbox is not modified the first line is an empty one. > > Question: > > Why is the M (sandbox modified) on a separate line? > > How do I get ‘1.8’ behavior back for this 1.9 version of svnversion? > > What exact version of TortoiseSVN 1.9.x do you use? Output of 'svn --version --verbose' command would be useful. If I remember correctly some TortoiseSVN builds was compiled using static runtime and this caused some problems with stdout flushing. -- Ivan Zhakov
Re: Subversion crashes on list with an empty format 3 repo
On 6 February 2016 at 01:49, Michael Osipov <micha...@apache.org> wrote: > Am 2016-02-05 um 22:10 schrieb Ivan Zhakov: >> >> On 5 February 2016 at 23:48, Michael Osipov <micha...@apache.org> wrote: >>> >>> Am 2016-02-05 um 20:31 schrieb Ivan Zhakov: >>>> >>>> >>>> On 5 February 2016 at 21:38, Michael Osipov <micha...@apache.org> wrote: >>>>> >>>>> >>>>> Hi folks, >>>>> >>>>> Subversion advised me to report this. >>>>> >>>>> The following command was performed: >>>>> svn --non-interactive list >>>>> >>>>> >>>>> file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn >>>>> >>>>> The repo is available here [1], the crash files are here [2]. >>>>> The issue can always be reproduced, it does not require to run the >>>>> tests >>>>> with Maven on Maven Wagon. >>>>> >>>> I cannot reproduce: >>>> [[[ >>>> svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn >>>> dummy >>>> >>>> C:\Program Files\VisualSVN Server\bin>svn --version >>>> svn, version 1.9.3 (r1718519) >>>> compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 >>> >>> >>> >>> After further testing, I think I know why it does not fail for you. You >>> have >>> downloaded a tarball snapshot of the repo via Gitweb. I have retried with >>> that one and Subversion does not crash. Aifter that, I ran SHA1 on all >>> files, cloned via Git and from the tarball, they are different because >>> Git >>> transforms the db files and aligned the line ending. >>> >>> svnadmin verify crashes too. >>> >>> These might shred the repo: >>> core.autocrlf=true >>> core.eol=native >>> core.safecrlf=true >>> >>> I have uploaded both repos to [1] as ZIP files. >>> >>> Can you kindly retry with a cloned repo or the ZIP files and report back? >>> >>> [1] http://home.apache.org/~michaelo/svn-crash-2016-02-05/ >>> >> I downloaded archive and now I'm getting error about wrong FS type as >> expected: >> [[[ >> C:\Program Files\VisualSVN Server\bin> --non-interactive >> file:///D:/Ivan/temp/repos/test-repo-svn >> svn: E170013: Unable to connect to a repository at URL >> 'file:///D:/Ivan/temp/repos/test-repo-svn' >> svn: E180001: Unable to open repository >> 'file:///D:/Ivan/temp/repos/test-repo-svn' >> 'vn: E160033: Invalid name for FS type 'fsfs >> ]]] > > > Picking up my previous response, I just tried binaries from VisualSVN > (probably the one you are using) and from SlikSVN. Both are working...is > that now an issue I have to raise with CollabNet or some hidden bug in > Subversion itself? > It could be some issue in CollabNet distribution, but we cannot investigate without debug symbols of Collabnet Subversion binaries. -- Ivan Zhakov
Re: Subversion crashes on list with an empty format 3 repo
On 5 February 2016 at 21:38, Michael Osipov <micha...@apache.org> wrote: > Hi folks, > > Subversion advised me to report this. > > The following command was performed: > svn --non-interactive list > file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn > > The repo is available here [1], the crash files are here [2]. > The issue can always be reproduced, it does not require to run the tests > with Maven on Maven Wagon. > I cannot reproduce: [[[ svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn dummy C:\Program Files\VisualSVN Server\bin>svn --version svn, version 1.9.3 (r1718519) compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 Copyright (C) 2015 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - using serf 1.3.8 (compiled with 1.3.8) - handles 'http' scheme - handles 'https' scheme The following authentication credential caches are available: * Wincrypt cache in C:\Users\ivan\AppData\Roaming\Subversion ]]] -- Ivan Zhakov
Re: Subversion crashes on list with an empty format 3 repo
On 5 February 2016 at 23:48, Michael Osipov <micha...@apache.org> wrote: > Am 2016-02-05 um 20:31 schrieb Ivan Zhakov: >> >> On 5 February 2016 at 21:38, Michael Osipov <micha...@apache.org> wrote: >>> >>> Hi folks, >>> >>> Subversion advised me to report this. >>> >>> The following command was performed: >>> svn --non-interactive list >>> >>> file:///D:/Entwicklung/Projekte/maven-wagon/wagon-providers/wagon-scm/src/test/resources/test-repo-svn >>> >>> The repo is available here [1], the crash files are here [2]. >>> The issue can always be reproduced, it does not require to run the tests >>> with Maven on Maven Wagon. >>> >> I cannot reproduce: >> [[[ >> svn --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn >> dummy >> >> C:\Program Files\VisualSVN Server\bin>svn --version >> svn, version 1.9.3 (r1718519) >> compiled Dec 15 2015, 11:23:08 on x86-microsoft-windows6.1.7601 > > > After further testing, I think I know why it does not fail for you. You have > downloaded a tarball snapshot of the repo via Gitweb. I have retried with > that one and Subversion does not crash. Aifter that, I ran SHA1 on all > files, cloned via Git and from the tarball, they are different because Git > transforms the db files and aligned the line ending. > > svnadmin verify crashes too. > > These might shred the repo: > core.autocrlf=true > core.eol=native > core.safecrlf=true > > I have uploaded both repos to [1] as ZIP files. > > Can you kindly retry with a cloned repo or the ZIP files and report back? > > [1] http://home.apache.org/~michaelo/svn-crash-2016-02-05/ > I downloaded archive and now I'm getting error about wrong FS type as expected: [[[ C:\Program Files\VisualSVN Server\bin> --non-interactive file:///D:/Ivan/temp/repos/test-repo-svn svn: E170013: Unable to connect to a repository at URL 'file:///D:/Ivan/temp/repos/test-repo-svn' svn: E180001: Unable to open repository 'file:///D:/Ivan/temp/repos/test-repo-svn' 'vn: E160033: Invalid name for FS type 'fsfs ]]] -- Ivan Zhakov
Re: Compiling ZLIB for svn 1.9.3 on Windows 7 using MSVC 2008
On 30 December 2015 at 19:06, Cooke, Mark <mark.co...@siemens.com> wrote: > [Updates below] > >> -Original Message- >> From: Cooke, Mark [mailto:mark.co...@siemens.com] >> Sent: 30 December 2015 15:56 >> >> Folks, >> >> I was having issues compiling httpd and svn for use with Trac (via the python >> 2.7 bindings). I have compiled httpd 2.4.18 (with apr 1.5.1, apr-util 1.5.4, >> apr-iconv 1.2.1, openssl 1.0.2e, pcre 1.3.8 and mod_wsgi 4.4.21) and am now >> trying to compile svn. >> >> I noted the comments about zlibstat and ZLIB_WINAPI [1][2], so I edited: >> - zconf.h (added #define ZLIB_WINAPI) >> - bld_ml32.bat (added the /safeseh switch to both lines) >> ...and ran: >> - vcbuild /rebuild contrib\vstudio\vc9\zlibvc.sln "Release|Win32" >> >> This seems to compile OK so I copied the zlibstat.lib up to the zlib root. >> >> [1] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL (section E4 >> ZLib) >> [2] http://www.tannerhelland.com/5076/compile-zlib-winapi-wapi-stdcall/ >> >> Next I built SERF 1.3.8: >> >> > scons.py APR=\svn\httpd\srclib\apr APU=\svn\httpd\srclib\apr-util >> OPENSSL=\svn\httpd\srclib\openssl ZLIB=\svn\zlib >> >> ...which reports success so I unpacked sqlite-amalgamation-3090200 and called >> gen-make: >> >> gen-make.py -t vcproj --vsnet-version=2008 --with-httpd=D:\svn\httpd --with- >> openssl=d:\svn\httpd\srclib\openssl --with-serf=d:\svn\serf --with- >> sqlite=d:\svn\sqlite --with-swig=c:\programs\swig --with-zlib=d:\svn\zlib >> >> ...and tried to build using subversion_vcnet.sln which resulted in lots of >> errors such as "error LNK2001: unresolved external symbol _inflate" for a >> number of functions that all look like they come from zlib (plus some >> expected errors due to not having Perl etc.) >> >> >> In the end I got it running by _removing_ all the ZLIB_WINAPI defines in the >> Visual Studio project files and _not_ defining ZLIB_WINAPI in the main config >> file: this is the opposite of the advice in [1]! >> >> Does this sound correct? If so I think the INSTALL file needs updating. > > I get one test failure but it looks bad:- > > START: checksum-test.exe > PASS: checksum-test 1: checksum parse > PASS: checksum-test 2: checksum emptiness > PASS: checksum-test 3: zero checksum matching > svn_tests: E26: Decompressed data doesn't match expected size or crc with > blocksize 17: Found crc32=0x3a74e3ee, size=241883. > Verify your ZLib installation, as this should never happen > FAIL: checksum-test 4: zlib expansion test (zlib regression) Zlib has known bug in assembly optimized code. Just disable assembly optimized code in zlib and everything should be fine. -- Ivan Zhakov
Re: Searching for compatible binary
On 4 December 2015 at 18:53, Stefan Hett <ste...@egosoft.com> wrote: > On 12/4/2015 4:42 PM, Stefan Hett wrote: >> >> On 12/4/2015 10:55 AM, Johan Wallström wrote: >>> >>> Hello, >>> >>> I'm searching for a binary release that can meet the following >>> requirements: >>> * Windows 64bit >>> * Supports file system format 7 (svn 1.9) >>> * Includes module-files for Apache 2.4 (latest wamp) >>> >>> I have found some binaries including svn 1.9, but supporting only AP2.2, >>> while other would support svn 1.8 with AP2.4 >>> >>> best regards >>> Johan >> >> Hi Johan, >> >> for testing purposes I think MaxSVN would meet these needs: >> http://www.luke1410.de/typo3/index.php?id=97 > > I just realized the Apache 2.4 modules are not packed alongside the archive. > If that would be helpful for you I could repackage them so you can use that > for testing. > I wouldn't recommend to use Apache HTTP Server and Subversion modules obtained from different source: different version of compile settings like Visual Studio runtime, used OpenSSL and APR version could produce different kind of errors. -- Ivan Zhakov
Re: svn crash
On 23 November 2015 at 09:52, Thomas Sußebach <thomas.susseb...@mgm-tp.com> wrote: > please find attached the minidump file > > > Version: 1.8.9 (r1591380), compiled May 8 2014, 13:53:02 Could you please update to the latest version (1.8.14 or 1.9.2) and try again. -- Ivan Zhakov
Re: Access Denied error on checkout to SMB share with 1.9.2, but not 1.8
On 22 October 2015 at 22:37, Winbow, Alexander G <alexander.g.win...@intel.com> wrote: > When trying to do a basic checkout, writing to a directory residing > on a SMB network share (netapp), I get intermittent errors "Can't stat > Access is denied". This happens with SVN 1.9.2 (or TortoiseSVN > 1.9.2), but not with SVN 1.18.14. > Could you please provide exact error message that you get? With filename and other stuff. This would help to find which operation actually failing. -- Ivan Zhakov
Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.
On 2 October 2015 at 11:06, Edward d'Auvergne <true.bug...@gmail.com> wrote: > Hi all, > > I was wondering if this should be considered a bug. At the FlightGear > project we have a 6 GB data svn repository for aircraft ( > https://sourceforge.net/projects/flightgear/ , > https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/ ). A large > quantity of the files, almost 30,000 in number, are XML text files. > > The problem is that modern Subversion clients appear to all be using > libmagic to determine the file type, to then set the svn:mime-type > property. However this is rather problematic: > > $ file -ib Aircraft/747-400/747-400-set.xml > application/xml; charset=us-ascii > > Libmagic detects all these XML files as "application/xml". Hence they > are treated as binary files! There are many other text files with > extensions such as *.ac, *.nas, etc. present in the repository that in > the future might be detected by libmagic as "application/xyz". > Easy fix would be change svn_mime_type_is_binary() to consider 'application/xml' as text file. We can also extend for other specific application/* mimetypes that are text files. We already have special handling for 'image/x-xbitmap' to consider it as text file. Does it make sense? -- Ivan Zhakov
Re: Access denied error on checkout-commit after updating to 1.9.X
On 7 September 2015 at 19:45, Ivan Zhakov <i...@visualsvn.com> wrote: > [Moving to dev@s.a.o] > > On 4 September 2015 at 18:15, Daniele Pedroni > <pedroni.dani...@zapispa.it> wrote: >> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN >> as well as command line throw the following error after trying to checkout >> or commit a Working Directory on a network share: >> >> Commit failed (details follow): >> Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to >> >> 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base': >> Access is denied. >> >> (full discussion on TSVN mailing list here: >> https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U ) >> >> It seems to be a Subversion issue, not a TortoiseSVN one, since command line >> acts exactly the same as TSVN: everything fine with local paths, issues with >> network drives. Sometimes, trying more and more, the checkout/commit >> succeeds also on network share, but it is a random occurrence. >> >> Any clue? As you can see in the suggested link, it seems that everyone who >> works on network drive has the same problem: something has been changed or >> broken in 1.9.X release about it? I didn’t find anything about it. >> > Bert and I were able to reproduce this issue with help from Daniele > and Marco. In short: Subversion 1.9.x doesn't work with working copies > stored on SMBv1 network shares (i.e. hosted on Windows XP/Windows > Server 2003 or Windows Server 2008 with SMBv2 disabled). It is not > related to background antivirus/indexers. So the bug affects many > users. > > While r1701298 fix still makes sense to workaround background > antivirus/indexers it doesn't help to fix Access Denied errors on > SMBv1 network shares. > > In nutshell problem is that SetFileInformationByHandle() API cannot be > called more than once if first call failed for any reason for SMBv1 > shares. We retry SetFileInformationByHandle() call if destination > directory doesn't exist or if we rename over read-only file. It works > fine for local directories or SMBv2 shares, but doesn't work for SMBv1 > network shares. SetFileInformationByHandle() returns > ERROR_ACCESS_DENIED without even sending request to SMB server. > > We developed patch that converts all ERROR_ACCESS_DENIED errors from > SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and > fallbacks to normal close + rename() (see attached file), but I'm not > sure it's the best solution and going to investigate this problem > tomorrow. > I didn't find better solution and committed this patch in r1701736. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Access denied error on checkout-commit after updating to 1.9.X
On 8 September 2015 at 13:12, Branko Čibej <br...@wandisco.com> wrote: > On 07.09.2015 18:42, Ivan Zhakov wrote: >> We developed patch that converts all ERROR_ACCESS_DENIED errors from >> SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and >> fallbacks to normal close + rename() (see attached file), but I'm not >> sure it's the best solution and going to investigate this problem >> tomorrow. > > Ideally, there'd be a way to check if the 'access denied' error is real, > or just a side effect of SMBv1. But I can't think of a reasonable way to > do this without (probably) incurring an unacceptable slowdown in the WC. > Agree. But I think r1701736 approach is acceptable, given that RenameByHandle code is performance optimization and 'access denied' error only happens when we retry rename after finding that target directory doesn't exists. So generally we don't get these access denied errors. -- Ivan Zhakov
Re: Access denied error on checkout-commit after updating to 1.9.X
On 7 September 2015 at 11:12, Daniele Pedroni <pedroni.dani...@zapispa.it> wrote: > Hi Ivan, > > thank you very much, but honestly speaking I don't know how to test it: I > installed SVN server through Redmine Bitnami package, and I update SVN on my > PC using TortoiseSVN installer. > If you provide me some suggestions about how to test it, I'll try it! > > Looking forward to hear from you soon, > Hi Daniele, This is client-side bug, there is no need to update server-side to test it. To test I'll send you compiled svn.exe, then you just need to extract it and run svn.exe update. Does it work for you? -- Ivan Zhakov
Re: Access denied error on checkout-commit after updating to 1.9.X
[Moving to dev@s.a.o]
On 4 September 2015 at 18:15, Daniele Pedroni
<pedroni.dani...@zapispa.it> wrote:
> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN
> as well as command line throw the following error after trying to checkout
> or commit a Working Directory on a network share:
>
> Commit failed (details follow):
> Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to
>
> 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base':
> Access is denied.
>
> (full discussion on TSVN mailing list here:
> https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U )
>
> It seems to be a Subversion issue, not a TortoiseSVN one, since command line
> acts exactly the same as TSVN: everything fine with local paths, issues with
> network drives. Sometimes, trying more and more, the checkout/commit
> succeeds also on network share, but it is a random occurrence.
>
> Any clue? As you can see in the suggested link, it seems that everyone who
> works on network drive has the same problem: something has been changed or
> broken in 1.9.X release about it? I didn’t find anything about it.
>
Bert and I were able to reproduce this issue with help from Daniele
and Marco. In short: Subversion 1.9.x doesn't work with working copies
stored on SMBv1 network shares (i.e. hosted on Windows XP/Windows
Server 2003 or Windows Server 2008 with SMBv2 disabled). It is not
related to background antivirus/indexers. So the bug affects many
users.
While r1701298 fix still makes sense to workaround background
antivirus/indexers it doesn't help to fix Access Denied errors on
SMBv1 network shares.
In nutshell problem is that SetFileInformationByHandle() API cannot be
called more than once if first call failed for any reason for SMBv1
shares. We retry SetFileInformationByHandle() call if destination
directory doesn't exist or if we rename over read-only file. It works
fine for local directories or SMBv2 shares, but doesn't work for SMBv1
network shares. SetFileInformationByHandle() returns
ERROR_ACCESS_DENIED without even sending request to SMB server.
We developed patch that converts all ERROR_ACCESS_DENIED errors from
SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and
fallbacks to normal close + rename() (see attached file), but I'm not
sure it's the best solution and going to investigate this problem
tomorrow.
--
Ivan Zhakov
Index: subversion/libsvn_subr/io.c
===
--- subversion/libsvn_subr/io.c (revision 1701642)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -2065,12 +2065,18 @@
rename_size);
}
- WIN32_RETRY_LOOP(status,
- win32_set_file_information_by_handle(hFile,
-FileRenameInfo,
-rename_info,
-rename_size));
+ /* Windows Vista+ client accessing network share stored on Windows Server
+ 2003 returns ERROR_ACCESS_DENIED. The same happens when Vista+ client
+ access Windows Server 2008 with disabled SMBv2 protocol.
+ So return SVN_ERR_UNSUPPORTED_FEATURE in this case like we do when
+ SetFileInformationByHandle() is not available and let caller to
+ handle it. */
+ if (status == APR_FROM_OS_ERROR(ERROR_ACCESS_DENIED))
+{
+ status = SVN_ERR_UNSUPPORTED_FEATURE;
+}
+
if (status)
{
return svn_error_wrap_apr(status, _("Can't move '%s' to '%s'"),
Re: Access denied error on checkout-commit after updating to 1.9.X
[Moving to dev@s.a.o]
On 4 September 2015 at 18:15, Daniele Pedroni
<pedroni.dani...@zapispa.it> wrote:
> After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN
> as well as command line throw the following error after trying to checkout
> or commit a Working Directory on a network share:
>
> Commit failed (details follow):
> Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to
>
> 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base':
> Access is denied.
>
> (full discussion on TSVN mailing list here:
> https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U )
>
> It seems to be a Subversion issue, not a TortoiseSVN one, since command line
> acts exactly the same as TSVN: everything fine with local paths, issues with
> network drives. Sometimes, trying more and more, the checkout/commit
> succeeds also on network share, but it is a random occurrence.
>
> Any clue? As you can see in the suggested link, it seems that everyone who
> works on network drive has the same problem: something has been changed or
> broken in 1.9.X release about it? I didn’t find anything about it.
>
Bert and I were able to reproduce this issue with help from Daniele
and Marco. In short: Subversion 1.9.x doesn't work with working copies
stored on SMBv1 network shares (i.e. hosted on Windows XP/Windows
Server 2003 or Windows Server 2008 with SMBv2 disabled). It is not
related to background antivirus/indexers. So the bug affects many
users.
While r1701298 fix still makes sense to workaround background
antivirus/indexers it doesn't help to fix Access Denied errors on
SMBv1 network shares.
In nutshell problem is that SetFileInformationByHandle() API cannot be
called more than once if first call failed for any reason for SMBv1
shares. We retry SetFileInformationByHandle() call if destination
directory doesn't exist or if we rename over read-only file. It works
fine for local directories or SMBv2 shares, but doesn't work for SMBv1
network shares. SetFileInformationByHandle() returns
ERROR_ACCESS_DENIED without even sending request to SMB server.
We developed patch that converts all ERROR_ACCESS_DENIED errors from
SetFileInformationByHandle() to SVN_ERR_UNSUPPORTED_FEATURE and
fallbacks to normal close + rename() (see attached file), but I'm not
sure it's the best solution and going to investigate this problem
tomorrow.
--
Ivan Zhakov
Index: subversion/libsvn_subr/io.c
===
--- subversion/libsvn_subr/io.c (revision 1701642)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -2065,12 +2065,18 @@
rename_size);
}
- WIN32_RETRY_LOOP(status,
- win32_set_file_information_by_handle(hFile,
-FileRenameInfo,
-rename_info,
-rename_size));
+ /* Windows Vista+ client accessing network share stored on Windows Server
+ 2003 returns ERROR_ACCESS_DENIED. The same happens when Vista+ client
+ access Windows Server 2008 with disabled SMBv2 protocol.
+ So return SVN_ERR_UNSUPPORTED_FEATURE in this case like we do when
+ SetFileInformationByHandle() is not available and let caller to
+ handle it. */
+ if (status == APR_FROM_OS_ERROR(ERROR_ACCESS_DENIED))
+{
+ status = SVN_ERR_UNSUPPORTED_FEATURE;
+}
+
if (status)
{
return svn_error_wrap_apr(status, _("Can't move '%s' to '%s'"),
Re: Access denied error on checkout-commit after updating to 1.9.X
On 4 September 2015 at 18:15, Daniele Pedroni <pedroni.dani...@zapispa.it> wrote: > After updating from 1.8.X to 1.9.X (tried also 1.9.1, no luck), TortoiseSVN > as well as command line throw the following error after trying to checkout > or commit a Working Directory on a network share: > > Commit failed (details follow): > Can't move 'U:\1-Administration\Management\.svn\tmp\svn-ADD80C28' to > > 'U:\1-Administration\Management\.svn\pristine\b7\b7c3f06170d83d3aac6b4489b78c4c8509c70ed6.svn-base': > Access is denied. > > > (full discussion on TSVN mailing list here: > https://groups.google.com/forum/#!topic/tortoisesvn/Goi-Ay3BV6U ) > > > It seems to be a Subversion issue, not a TortoiseSVN one, since command line > acts exactly the same as TSVN: everything fine with local paths, issues with > network drives. Sometimes, trying more and more, the checkout/commit > succeeds also on network share, but it is a random occurrence. > > Any clue? As you can see in the suggested link, it seems that everyone who > works on network drive has the same problem: something has been changed or > broken in 1.9.X release about it? I didn’t find anything about it. > I've attempted to fix this problem in r1701298 [1]. Could you test it? I may provide development build of Subversion with this fix if needed. [1] http://svn.apache.org/r1701298 -- Ivan Zhakov
Re: Subversion 1.9.1 and SVNParentPath
On 3 September 2015 at 11:18, Branko Čibej <br...@wandisco.com> wrote: > On 03.09.2015 09:42, Tony Butt wrote: >> Problem: Cannot access svn repos using SVNParentPath and subversion >> 1.9.1 >> >> Environment: >> Ubuntu 14.04, Apache 2.4.7, Subversion 1.9.1, mod_auth_kerb >> >> Apache config snippet: >> >> >> >>DAV svn >>SVNParentPath /srv/svn/repos/ >>SVNListParentPath on >> >>SVNIndexXSLT "/svnindex.xsl" >> >> # Compression options >>AddOutputFilterByType DEFLATE text/html text/plain text/xml >>SetInputFilter DEFLATE >> >> # Krb Authentication >>Include /etc/apache2/krb.conf >> >>AuthDBMType default >>AuthDBMGroupFile /srv/www/groupsdb >> >> Require group software hardware >> Require valid-user >> >> >>AuthZSVNAccessFile /srv/svn/access >> >> >> >> >> >> I installed the subversion 1.9.0 RC a little while back on this machine, >> all OK. >> Installed subversion 1.9.0 release Monday, had to set >> --enable-broken-httpd-auth >> to build successfully. Went to the apache config and ensured that no >> unauthenticated access was possible to the document root. All OK. >> >> I installed subversion 1.9.1 yesterday, built and installed OK. >> On testing repos access, I can browse to http://hostname/repos/ , >> but any attempt to access http://hostname/repos/name1 >> fails, with this message at the browser. >> >> "Unauthorized This server could not verify that you are authorized to >> access the document requested. Either you supplied the wrong credentials >> (e.g., bad password), or your browser doesn't understand how to supply >> the credentials required." >> >> Reverting to Subversion 1.8.13, or 1.9.0 resolves this. >> Changing the configuration top not use SVNParentPath, by specifying >> individual repositories with SVNPath resolves this too. >> Some interaction between the svnauthz changes and SVNParentPath seems to >> be broken > > When you upgraded Subversion, did you also restart httpd? (Using > 'apachectl graceful' or 'apachectl restart' or reasonable equivalent.) > The only relevant change in Subversion 1.9.1 compared to 1.9.0 is 1698052 [1]: [[[ Merge the r1687304 group from trunk: * r1687304,1687389,1693135,1693138,1693159,1695600,1695606,1695681 Better configure detection of httpd version and auth fix. Justification: Build out-of-the box on more platforms. Votes: +1: philip, stefan2, brane ]]] [1] http://svn.apache.org/viewvc?view=revision=1698052 -- Ivan Zhakov
Re: Feature request: Save the old file when svn revert
On 21 July 2015 at 11:38, Andreas Stieger andreas.stie...@gmx.de wrote: Hello, David Grierson wrote: svn revert will delete the local changes and nowhere to find, which is dangerous. I suggest the default behaiver should be save the local changed file(if any) to filename.local and do the revert. That's actually not a bad idea ... I've been burnt by this one a couple of times myself. Probably worth raising it with the d...@subversion.apache.org list to see if it's something that they've considered previously. Actually a feature in at least one GUI client: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html#tsvn-dug-settings-dialogs Otherwise it's rather platform specific to implement, and may be better suited for integrated clients. I think best solution is to move reverted files to Recycle Bin if it present on platform. Many platforms seems to have Recycle Bin concept these days: Recycle Bin on Windows, ~/.Trash on Ubuntu and Trash on Mac OS [1] [1] http://www.hardcoded.net/articles/send-files-to-trash-on-all-platforms -- Ivan Zhakov
Re: Cannot checkout or clean up using 1.9 dev build
On 28 April 2015 at 16:15, Benjamin Fritz fritzophre...@gmail.com wrote: On Apr 28, 2015 8:02 AM, Ivan Zhakov i...@visualsvn.com wrote: I've fixed at least one problem in svn_stream__install*() on Windows with long path names in r1676526. But I was getting different error message on Windows 8.1. Benjamin, what operating system do you use? Windows 7 Thanks! I've tested and I'm getting the same error as you reported on Windows 7, so problem is very likely fixed in r1676526. I'm going to nominate it to 1.9.x then. -- Ivan Zhakov
Re: Cannot checkout or clean up using 1.9 dev build
On 28 April 2015 at 10:07, Ivan Zhakov i...@visualsvn.com wrote: On 27 April 2015 at 21:35, Benjamin Fritz fritzophre...@gmail.com wrote: Apparently I'm not subscribed to get list emails; please CC me on future responses. I had to get this message from the archive :-) Branko Čibej wrote: On 27.04.2015 18:06, Benjamin Fritz wrote: I get the following error when I try to check out a working copy from my repository at work (exact path names obfuscated but length unchanged, in case it matters It probably does matter ... FWIW, I believe you did change the length of the file name, the workqueue record says 234 chars but the name in the record is 240; still, that shouldn't be an issue. Oops. You're right. My actual directory has only 3 characters where I replaced with Prog in the path string. Still, those 6 fewer characters are probably irrelevant. ), leaving a partially downloaded working copy: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. The full path of the file would be 281 characters long, which is more than Windows' limit of 260. But Subversion goes to a lot of trouble to avoid the path limit ... I wonder what's going on here. It seems Windows specific implementation of svn_stream__install_stream() doesn't prepend path with \\?\ for long names. Replacing svn_utf__win32_utf8_to_utf16() call with svn_io__utf8_to_unicode_longpath() should fix the problem, but I didn't try yet. I've fixed at least one problem in svn_stream__install*() on Windows with long path names in r1676526. But I was getting different error message on Windows 8.1. Benjamin, what operating system do you use? -- Ivan Zhakov
Re: Cannot checkout or clean up using 1.9 dev build
On 27 April 2015 at 21:35, Benjamin Fritz fritzophre...@gmail.com wrote: Apparently I'm not subscribed to get list emails; please CC me on future responses. I had to get this message from the archive :-) Branko Čibej wrote: On 27.04.2015 18:06, Benjamin Fritz wrote: I get the following error when I try to check out a working copy from my repository at work (exact path names obfuscated but length unchanged, in case it matters It probably does matter ... FWIW, I believe you did change the length of the file name, the workqueue record says 234 chars but the name in the record is 240; still, that shouldn't be an issue. Oops. You're right. My actual directory has only 3 characters where I replaced with Prog in the path string. Still, those 6 fewer characters are probably irrelevant. ), leaving a partially downloaded working copy: svn: E155009: Failed to run the WC DB work queue associated with 'C:\Project_Files\Proj_Dev\Prog_svn_1.9_cmdline', work item 2160 (file-install 234 Logical_Architecture/APP/App_PL_Verification/XXX/XXX_XXXs/XXX_7_APPDB_PROJ_PROG--0021_BE/APPDB_PROJ_PROG--0021.SUP/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021/APPDB_PROJ_PROG--0021.SUP/XXX_APPDB_PROJ_PROG--002101.CRC 1 0 1 1) svn: E720123: The filename, directory name, or volume label syntax is incorrect. The full path of the file would be 281 characters long, which is more than Windows' limit of 260. But Subversion goes to a lot of trouble to avoid the path limit ... I wonder what's going on here. It seems Windows specific implementation of svn_stream__install_stream() doesn't prepend path with \\?\ for long names. Replacing svn_utf__win32_utf8_to_utf16() call with svn_io__utf8_to_unicode_longpath() should fix the problem, but I didn't try yet. Bert, is it intentional behavior or just small typo? -- Ivan Zhakov
Re: Exception: libsvn_wc\update_editor.c line 1550: assertion failed (action == svn_wc_conflict_action_delete)
On 14 March 2015 at 22:57, Bert Huijben b...@qqmail.nl wrote: Hi, Thanks for noting that this is related to the github implementation. When Subversion recovers from an so called ‘incomplete’ update, it sends other information to the server, but the github Subversion compatibility code doesn’t properly implement this recovery code path. (Their server also has problems handling sparse working copies… something that is not possible in plain git) There is not much we can do here in Subversion, as this is technically a protocol violation. But if github needs more information for fixing this please let them contact me. Hi Bert, I didn't look to the code, but is it possible to replace assertion with some error message for this case? -- Ivan Zhakov
Re: Subversion 1.8 freezes during long updates
On 1 July 2014 21:45, Butler, Stephen stephen.but...@hamburgsud.com wrote: Hi folks, I'm trying to help users in our corporate network. They currently use Subversion 1.7 + neon (via TortoiseSVN) because of errors in checkout/update using Subversion 1.8. During a long checkout or update, TortoiseSVN 1.8 freezes after downloading a few hundred MBs of data. The svn command-line client does the same. To get more information, I compiled Subversion (within the TortoiseSVN branches/1.8.x tree) with serf tracing turned up to eleven (SSL_MSG_VERBOSE, etc). Then the errors no longer occur! Apparently the extra output changes the timing somehow. But performance is of course very bad. Less tracing recreates the errors, but without revealing a smoking gun. I attached the Visual Studio debugger to a frozen cmdline client. It seemed to be looping through impl_pollset_poll (in apr/poll/unix/select.c) without receiving anything. On the Subversion server, the last message in the Apache access log is a successful file download (matching the last line of client output). The Apache error log had nothing new. The network has lots of firewalls and transparent proxies, as was the case in a problem that Branko recently solved: http://mail-archives.apache.org/mod_mbox/subversion-users/201401.mbox/%3C52D6D944.8060308%40wandisco.com%3E Should I try to corner the network admins, or is there a client/server troubleshooting step I've overlooked? Thanks for any insights, Hi Steve, 1. Does the issue reproduce if you force bulk updates using '--config-option=servers:global:http-bulk-updates=yes' command line option or 'SVNAllowBulkUpdates prefer' on the server side? 2. Do you have antivirus installed on client computers? -- Ivan Zhakov
Re: Subversion 1.8 freezes during long updates
On 2 July 2014 17:05, Butler, Stephen stephen.but...@hamburgsud.com wrote: -Original Message- From: Ivan Zhakov [mailto:i...@visualsvn.com] Sent: Wednesday, July 02, 2014 14:31 To: Butler, Stephen Cc: users@subversion.apache.org Subject: Re: Subversion 1.8 freezes during long updates On 1 July 2014 21:45, Butler, Stephen stephen.but...@hamburgsud.com wrote: Hi folks, I'm trying to help users in our corporate network. They currently use Subversion 1.7 + neon (via TortoiseSVN) because of errors in checkout/update using Subversion 1.8. During a long checkout or update, TortoiseSVN 1.8 freezes after downloading a few hundred MBs of data. The svn command-line client does the same. To get more information, I compiled Subversion (within the TortoiseSVN branches/1.8.x tree) with serf tracing turned up to eleven (SSL_MSG_VERBOSE, etc). Then the errors no longer occur! Apparently the extra output changes the timing somehow. But performance is of course very bad. Less tracing recreates the errors, but without revealing a smoking gun. I attached the Visual Studio debugger to a frozen cmdline client. It seemed to be looping through impl_pollset_poll (in apr/poll/unix/select.c) without receiving anything. On the Subversion server, the last message in the Apache access log is a successful file download (matching the last line of client output). The Apache error log had nothing new. The network has lots of firewalls and transparent proxies, as was the case in a problem that Branko recently solved: http://mail-archives.apache.org/mod_mbox/subversion-users/201401.mbox/ %3C52D6D944.8060308%40wandisco.com%3E Should I try to corner the network admins, or is there a client/server troubleshooting step I've overlooked? Thanks for any insights, Hi Steve, 1. Does the issue reproduce if you force bulk updates using '--config-option=servers:global:http-bulk-updates=yes' command line option or 'SVNAllowBulkUpdates prefer' on the server side? Setting either option seems to solve the problem completely. I should have read the release notes more carefully! 2. Do you have antivirus installed on client computers? FWIW, yes, but in this case it was mostly harmless. It still will be interesting to investigate the issue. Could please specify what antivirus/firewall used on client computer? Does it have any active/filtering protection? -- Ivan Zhakov
Re: SVN issue
On 30 March 2014 15:28, Omer Abramovich om...@syverse.net wrote: Hello, After setting up SVN protocol (using svnserve windows process) I get this kind of error when perform commit. Hi Omer, This issue is fixed in recently released VisualSVN Server 2.7.5: * Fixed: VisualSVNServerHooks.exe crashes on commits without 'svn:log' or 'svn:author' properties. http://www.visualsvn.com/server/download/ -- Ivan Zhakov http://www.visualsvn.com
Re: Subversion checked-out files not indexed in Windows search
On 10 March 2014 18:25, Gareth McCaughan gareth.mccaug...@lightblueoptics.com wrote: It appears that files checked out using Subversion (1.7 onwards) are marked as not indexable by Windows search. The way in which this happens appears to be as follows: When the WC is created: 1. .svn directory is created, and marked as hidden and not indexable. 2. .svn/tmp directory is created, and inherits that not-indexable property. (Or maybe it's given it explicitly; I haven't checked.) On checkout: 1. Temporary file is created under .svn, and accordingly gets its not-indexable flag set. 2. Temporary file is moved to its proper location; this doesn't cause the not-indexable flag to be cleared. So the point is that the NOT_CONTENT_INDEXABLE attribute on a directory doesn't exactly mean don't search inside this directory but make files created in this directory searchable. Then when they get moved elsewhere they retain that unsearchability. (If skeptical, you can see this by hand on a Windows machine, as follows: Create a directory A and subdirectory A\B. Right-click on B, select Properties, select Advanced, uncheck the allow-indexing box. Create two files A\B\C.txt and A\B\D.txt and put the word wombat in each. Now right-click D.txt, select Properties, select Advanced, and *check* the allow-indexing box; and drag C.txt out of A\B and into A. Now, in A, search for wombat using Windows Search. It will find D.txt even though it's in the unsearchable folder A\B, and it will not find C.txt even though it's in the searchable folder A, because what actually matters is the attributes on the files.) * Windows Search is of course generally a poor tool for searching source code, but this still seems fairly clearly (1) unintended and (2) undesirable. Should I file an issue? If not, will someone else? * I am not familiar with the code responsible for this, but a little browsing suggests that the rename is being done in svn_stream__install_stream (called from run_file_install in libsvn_wc/workqueue.c) by a call to SetFileInformationByHandle, and that this function is capable of changing the file attributes at the same time as doing the rename. I make no claim that this would actually be a good solution. * (Note 1. This seems to have been reported informally a couple of times before, but I don't see that it's ever received an official answer, had an issue filed in the Subversion issue tracker, or been fixed. Apologies if it has and I've missed it.) (Note 2. I have observed the behaviour described above on Windows 7 using svn 1.7.5, and on Windows 8 using svn 1.8.3. There is nothing in the CHANGES file to suggest it's likely to have been fixed since then, but I can check with the latest release if that's necessary.) (Note 3. I am not subscribed to users@ but will check for replies in the online archives; best to Cc: me, though, if you have questions or comments you want to be sure I'll see.) It looks like serious issue. Could you please file issue in Subversion issue tracker: http://subversion.tigris.org/issues -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Request help to analyze a crash problem
On 4 March 2014 01:48, Nielson, Mark (Omaha) mark.niel...@hp.com wrote: Requesting help to analyze a crash problem when performing a getUmbrella: MNielson@MNIELSON2 ~/svn/IHSS/trunk/IMS/build/OSSI_1a/build $ getU --verbose HSS_ALL trunk IHSS/trunk Get Packages to WA: /home/MNielson/svn/IHSS/trunk You're using Subversion 1.6.16 which is very old and not supported: http://subversion.apache.org/docs/release-notes/1.8.html#svn-1.6-deprecation I recommend you upgrade to latest Subversion 1.8 first. -- Ivan Zhakov
Re: svn hotcopy
On 27 December 2013 00:42, Listman list@bluejeantime.com wrote: I am using svn 1.5.5 and I backup with hotcopy. I am starting to see that my repository which 50G is backing up as 48G with hotcopy. I can’t figure it out and my friend google is not helping at all. Does any one have a clue? As far I remember 'svnadmin hotcopy' doesn't copy uncommitted transactions. They are stored in db\transactions folder in repository. You may get several uncommitted and not properly aborted transactions for long lived repositories. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: size of .svn/pristine directory (svn 1.7.x)
On 9 December 2013 21:55, Daniel Shahaf d...@daniel.shahaf.name wrote: Vincent Lefevre wrote on Mon, Dec 09, 2013 at 17:30:21 +0100: I noticed that the size of the .svn/pristine directory can get huge over time (several times the expected size). A svn cleanup solves the problem, but 1. this isn't documented (I'm wondering how many users know that); It's documented in the 1.7 release notes. http://subversion.apache.org/docs/release-notes/1.7#wc-pristines 2. this isn't automatic. Yes, that's a known bug that we need to fix someday. Btw it's not a bug for some use cases: Subversion doesn't download files if user switches to branch and then back to trunk. Which is very useful in some scenarios. -- Ivan Zhakov
Re: size of .svn/pristine directory (svn 1.7.x)
On 10 December 2013 01:32, Daniel Shahaf d...@daniel.shahaf.name wrote: Ivan Zhakov wrote on Tue, Dec 10, 2013 at 01:00:32 +0400: On 9 December 2013 21:55, Daniel Shahaf d...@daniel.shahaf.name wrote: Vincent Lefevre wrote on Mon, Dec 09, 2013 at 17:30:21 +0100: I noticed that the size of the .svn/pristine directory can get huge over time (several times the expected size). A svn cleanup solves the problem, but 1. this isn't documented (I'm wondering how many users know that); It's documented in the 1.7 release notes. http://subversion.apache.org/docs/release-notes/1.7#wc-pristines 2. this isn't automatic. Yes, that's a known bug that we need to fix someday. Btw it's not a bug for some use cases: Subversion doesn't download files if user switches to branch and then back to trunk. Which is very useful in some scenarios. Agreed, that'd be an argument for not deleting pristines *as soon as* they're not necessary, but less often then that. You should mention it on the aforelinked issue ticket if it's not already there :) Done. Thanks for suggestion! -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Issues with mod_dav in httpd 2.2.25 and 2.4.6
On 8 November 2013 09:46, Ben Reser b...@reser.org wrote: The current releases of httpd (at the time of writing this email) have two issues when used with Subversion. At this point httpd doesn't release very often leaving some users with an unfortunate choice to leave their httpd unpatched from some security issues fixed by those releases or to deal with these additional bugs introduced in recent versions of httpd. In order to help the end users I've put together some patches (that should be included in the next releases of Apache httpd) that resolve these issues. * PR 55397 : ABI change in mod_dav causes failures with older versions of SVN https://issues.apache.org/bugzilla/show_bug.cgi?id=55397 [...] * PR 55306 : COPY fails when source is locked https://issues.apache.org/bugzilla/show_bug.cgi?id=55306 Hi Ben, Thanks for great summary on these problems! I believe some binary packages have included these patches already. But I'm not sure which ones have and have not. Hopefully those vendors can respond here to note that. VisualSVN Server distribution includes both mentioned patches since version 2.6.5: http://www.visualsvn.com/server/download/ -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: E120104: ra_serf: An error occurred during decompression
I'll post a patch to Stefan, but we should add test for this zlib issue to Subversion test suite imho. On 30 October 2013 17:35, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Ben Reser [mailto:b...@reser.org] Sent: dinsdag 29 oktober 2013 23:31 To: Jeff Dege; users@subversion.apache.org Subject: Re: E120104: ra_serf: An error occurred during decompression On 10/29/13 1:48 PM, Jeff Dege wrote: ra_serf: An error occurred during decompression This looks to be another case of the ZLib assembly optimizations as described here: https://mail-archives.apache.org/mod_mbox/subversion- dev/201309.mbox/%3C003c01ceaf28%24aab563d0%2400202b70%24%40qqm ail.nl%3E Some specific recommendations here (that may not be particularly helpful unless you're building your own client): https://mail-archives.apache.org/mod_mbox/subversion- dev/201310.mbox/%3C00d301ced163%2451c733e0%24f5559ba0%24%40qqm ail.nl%3E Can you try with compression turned off and see if the issues disappears? I'm not sure if TortoiseSVN is using a ZLib with the assembly optimizations enabled, that would probably be something to bring to their lists. Just checked the source for TortoiseSVN trunk: yes they do use the assembly optimizations. Bert -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re:
On 23 October 2013 16:43, Neidecker, Stanley K stanley.k.neidec...@centurylink.com wrote: C:\bea\workspace-31-FX\MAD2svn update It seems you're using very old version (Subversion 1.6.20 (r1426281). Subversion 1.6.x series no longer supported: http://subversion.apache.org/docs/release-notes/1.8.html#svn-1.6-deprecation -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: svn 1.8.3 on windows often crashes
On 18 October 2013 18:06, Karol Szkudlarek ka...@mikronika.com.pl wrote: I'm asked about: OK. So please tell me whether this fix (r152289) for issue #4425 is already merged to branch 1.8.x?!( Ivan's answer is not enough for me. Ivan wrote: Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. I don't know whether r1522892 is in trunk (I suppose this) or in destination branch 1.8.x. Yes, r1522892 was merged to 1.8.x branch and other user tested 1.8.x command line binaries (from TortoiseSVN) and confirmed that issue fixed: http://svn.haxx.se/users/archive-2013-10/0110.shtml -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: svn log hang
On 16 October 2013 16:36, Kaltenberger, Stefan
stefan.kaltenber...@fabasoft.com wrote:
Hi,
I recently upgraded my Subversion client from version 1.7.5 to 1.8.3 and
from that time on I experience hangs when executing multiple 'svn log'
commands in a short amount of time. The hanging svn process consumes
all CPU cycles it gets but never finishes.
I can reproduce the problem using the following shell script (on Windows
using Cygwin):
#!/bin/bash
ROOT=http://example.com/svn/trunk;
for DIR in $(svn ls ${ROOT} | head -n 4); do
svn log -v -l 5 ${ROOT}/${DIR} 21 | head -n 100 /dev/null
done
In my environment I need at least 4 svn processes to achieve the faulty
behavior. The hang only occurs if the output is truncated using the head
command (but it can be redirected to a normal file instead of /dev/null
which then contains the expected log messages).
It seems like issue #4425 [1] which is fixed in r1522892 and proposed
for backport to Subversion
1.8.4.
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn 1.8.3 on windows often crashes
I'm trying to use the latest 1.8.3 64-bit version of svn client: CollabNetSubversion-client-1.8.3-1-x64.exe but several times crashes. In attachement are log and dmp. Hi, The attached dumps and logs doesn't have debug symbols included, this we're unable to investigate the issue. I recommend you contact company produced this binaries (CollabNet) or try to reproduce problem with other Subversion binaries distribution and contact them. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: svn 1.8.3 on windows often crashes
On 4 October 2013 16:44, Ivan Zhakov i...@visualsvn.com wrote: I'm trying to use the latest 1.8.3 64-bit version of svn client: CollabNetSubversion-client-1.8.3-1-x64.exe but several times crashes. In attachement are log and dmp. Hi, The attached dumps and logs doesn't have debug symbols included, this we're unable to investigate the issue. I recommend you contact company produced this binaries (CollabNet) or try to reproduce problem with other Subversion binaries distribution and contact them. Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: svn 1.8.3 on windows often crashes
On 4 October 2013 17:00, Karol Szkudlarek ka...@mikronika.com.pl wrote: W dniu 2013-10-04 14:50, Ivan Zhakov pisze: On 4 October 2013 16:44, Ivan Zhakov i...@visualsvn.com wrote: I'm trying to use the latest 1.8.3 64-bit version of svn client: CollabNetSubversion-client-1.8.3-1-x64.exe but several times crashes. In attachement are log and dmp. Hi, The attached dumps and logs doesn't have debug symbols included, this we're unable to investigate the issue. I recommend you contact company produced this binaries (CollabNet) or try to reproduce problem with other Subversion binaries distribution and contact them. Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Well, yes it looks like exactly my problem. Thanks for info about. When the 1.8.4 will be released? Now its very annoying crash. I do 'svn log' very often. :-) There is no specific schedule for patch releases. Usually they come not less often than every month and if important fixes are waiting for release. Subversion 1.8.3 was released 29 August 2013. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: second commit is failing if space is in file name or file path
On 30 September 2013 17:42, Kesavan Sengodan kesavan.sengo...@lmsintl.com wrote: Dear Ivan Zhakov, The solution URL has only the source code. Compiling it is big task. Is there any binary available for this solution? If yes, where can we get it? Kindly help us. VisualSVN Server has these fixes applied, so I recommend you give a try if you're using Subversion on Windows: http://www.visualsvn.com/server/ -- Ivan Zhakov
Re: second commit is failing if space is in file name or file path
On 25 September 2013 18:50, Kesavan Sengodan kesavan.sengo...@lmsintl.com wrote: Hi We are using Subversion (SVN 1.6.12-r955802) for our repo. This subversion and the modules (dav_svn_module authz_svn_module) provided by it, are working fine with previous Apache version 2.2.24. It's known problem in Apache HTTP Server 2.2.25: https://issues.apache.org/bugzilla/show_bug.cgi?id=55397 The only known solution is to revert these buggy changes in Apache HTTP Server: http://svn.haxx.se/dev/archive-2013-08/0479.shtml -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: svn: E195016: merge error is dropping last character of path
On Wed, Sep 11, 2013 at 5:19 PM, Andrew Reedick andrew.reed...@cbeyond.net wrote: So... any reason why the last character in paths are getting dropped in the Missing ranges: output? Ex: the k is missing from trunk in Missing ranges: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 Or, maybe the problem is limited to the first entry? Ex: the 'g' is getting left off in the first Missing ranges. portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 More importantly, if the first pathname is getting mangled, is it affecting how merges are resolved/calculated? Or is it just a presentation bug? This is 1.8.3 cygwin CLI client and in TortoiseSVN 1.8.1. == svn: E195016: Reintegrate can only be used if revisions 4109 through 4928 were previously merged from https://server/some/where/branches/foo to the reintegrate source, but this is not the case: portal/trunk Missing ranges: /portal/trun:4125,4143,4145,4147,4150,4163,4166,4168,4170,4209,4217,4222,4252,4277,4282,4300,4364,4375,4383,4459,4465,4469 portal/trunk/config Missing ranges: /portal/trunk/confi:4217,4378,4459 Missing ranges: /portal/trunk/config:4387,4435,4452 Hi, Andrew. Could you check value of svn:mergeinfo properties on /portal/trunk and /portal/trunk/config in repository AND working copy to identify where merge info was corrupted. Thanks! -- Ivan Zhakov
Re: svn.exe crashed when output of 'log' command interrupted
On Fri, Sep 13, 2013 at 3:43 PM, Ivan Zhakov i...@visualsvn.com wrote: On Thu, Sep 12, 2013 at 10:53 AM, Sergey Azarkevich azarkev...@gmail.com wrote: Reproduced on: svn, version 1.8.4-dev (under development) compiled Aug 23 2013, 17:30:38 on x86-microsoft-windows svn, version 1.8.3 (r1516576) compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows svn, version 1.8.0 (r1490375) compiled Jun 18 2013, 13:38:49 on x86/x86_64-microsoft-windows6.1.7601 Windows + cygwin. Steps: svn.exe log | less show first N log entries. Then press 'q' for exit. svn.exe application crashed. Same crash for svn.exe log | more Filed as issue #4425: http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Simple fix is coming soon. Fixed in r1522892 and nominated for backport to 1.8.x. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: svn.exe crashed when output of 'log' command interrupted
On Thu, Sep 12, 2013 at 10:53 AM, Sergey Azarkevich azarkev...@gmail.com wrote: Reproduced on: svn, version 1.8.4-dev (under development) compiled Aug 23 2013, 17:30:38 on x86-microsoft-windows svn, version 1.8.3 (r1516576) compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows svn, version 1.8.0 (r1490375) compiled Jun 18 2013, 13:38:49 on x86/x86_64-microsoft-windows6.1.7601 Windows + cygwin. Steps: svn.exe log | less show first N log entries. Then press 'q' for exit. svn.exe application crashed. Same crash for svn.exe log | more Filed as issue #4425: http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Simple fix is coming soon. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Issue 4039
Johan, I think it may be worth to close issue 4039 as won't fix in this case. Since it's extremely low chance that we go back to have .svn per every directory. On Tue, Aug 20, 2013 at 3:13 PM, Angelo Tavares ang...@mega.com.br wrote: Yes, I have subst M: C:\SomeDir\Project\subdir, but thanks for the feedback. With subst M: C:\SomeDir\Project, works very well indeed 2013/8/19 Johan Corveleyn jcor...@gmail.com On Mon, Aug 19, 2013 at 9:25 PM, Angelo Tavares ang...@mega.com.br wrote: My case is creating subst working areas, which is not presented the features of subversion. Can you please give a bit more detail? What do you mean by creating subst working areas? Do you mean, for instance, that you have a working copy in C:\SomeDir\Project (which is the root of the working copy), and you execute subst M: C:\SomeDir\Project? If so, that works fine (just tried it with 1.7 and 1.8). But if you want subst M: C:\SomeDir\Project\subdir, that won't work, and like Ivan said, will probably never be fixed (it really doesn't fit with the working copy design of 1.7+, where all SVN metadata is centralized in the root of the working copy). -- Johan -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Cannot check out public directory with client 1.8.x without access to repo root
On Wed, Aug 21, 2013 at 4:17 AM, Mark Tsuchida marktsuch...@gmail.com wrote: Hi Ivan, On Tue, Aug 20, 2013 at 12:02 AM, Ivan Zhakov i...@visualsvn.com wrote: On Mon, Aug 19, 2013 at 11:14 PM, Ivan Zhakov i...@visualsvn.com wrote: On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida marktsuch...@gmail.com wrote: [...] The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS. Our repository (let's call it myrepo) allows public read access (* = r) to myrepo/trunk, but not to myrepo/ (the root). There is also a directory myrepo/trunk/secret to which only specific users have access to. Everything has been working as expected with SVN 1.6 and 1.7 clients: in particular, no username or password is requested when checking out myrepo/trunk. However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check out any directory without supplying the credentials of a user who has access to the repository root. svn co https://our.server.com/svn/myrepo/trunk - Requires authentication with client 1.8.x but not with 1.6.x or 1.7.x svn list https://our.server.com/svn/myrepo/trunk - Works even with 1.8.1 svn list https://our.server.com/svn/myrepo - Requires auth, as expected [...] The following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.6.18 (OS X): xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] OPTIONS /svn/myrepo/trunk HTTP/1.1 200 197 [...] /svn/myrepo/!svn/vcc/default HTTP/1.1 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1 207 479 And the following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows 7): xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] OPTIONS /svn/myrepo/trunk HTTP/1.1 200 197 [...] xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] PROPFIND /svn/myrepo/!svn/bc/123 HTTP/1.1 401 483 It should be 403 Forbidden, not 401 Unauthorized. Looks like some issue with server configuration. I can get the server to return 403 Forbidden for https://our.server.com/svn/myrepo by removing Require valid-user from our Apache config. This does seem to allow the anonymous checkout of https://our.server.com/svn/myrepo/trunk to succeed. But this also prevents the client from asking for a password altogether when checking out e.g. https://our.server.com/svn/myrepo, which is not the desired behavior. The problem here that when checking out Subversion requests properties for every parent if server doesn't support retrieving them in special request introduced in Subversion 1.8. But anonymous user doesn't have access to repository root and server responds 401 Unauthorized, which means no anonymous access, give me valid credentials. The first bug here why Subversion 1.8 doesn't ask you for credentials on checkout like it does for commit. It appears that the 1.8.1 client requests /svn/myrepo/!svn/bc/123, to which access is denied (401), whereas client 1.6.18 only ever requests /svn/myrepo/!svn/bc/123/trunk, to which access is granted. Most likely it is some problem with inherited properties feature implemented in Subversion 1.8. The issue doesn't reproduces with server configured for non-anonymous access: the server returns 401 Forbidden for PROPFIND request on repository root and handled properly by Subversion 1.8 client. (I assume you meant 403 Forbidden.) Yes, I meant 403 Forbidden. Sorry. Does that still allow checking out the root by users who do have read permission for the root Yes, checking out working copy without access to repository root is supported in Subversion 1.8. But it seems that anonymous check out without access to repository root is broken now. Can you perhaps spot an error in my authz and apache configs (please see my reply to Daniel)? Did you try replace Satisfy Any to Satisfy All ? I think at current state you have to options: 1. Upgrade server to Subversion 1.8 2. Create 'guest' user and disable anonymous access It sill will be useful to file bug in Subversion issue tracker though. -- Ivan Zhakov
Re: Cannot check out public directory with client 1.8.x without access to repo root
On Wed, Aug 21, 2013 at 12:01 PM, Ben Reser b...@reser.org wrote: On Wed Aug 21 00:17:08 2013, Ivan Zhakov wrote: The first bug here why Subversion 1.8 doesn't ask you for credentials on checkout like it does for commit. Known limitation of HTTP, see the Partial Readability on Checkouts block at the bottom of this page: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html The problem that server responds 401 and client doesn't ask for credentials, while it should be. -- Ivan Zhakov
Re: Cannot check out public directory with client 1.8.x without access to repo root
On Mon, Aug 19, 2013 at 11:14 PM, Ivan Zhakov i...@visualsvn.com wrote: On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida marktsuch...@gmail.com wrote: Hello, I'm having an issue with our partially-public SVN repository. The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS. Our repository (let's call it myrepo) allows public read access (* = r) to myrepo/trunk, but not to myrepo/ (the root). There is also a directory myrepo/trunk/secret to which only specific users have access to. Everything has been working as expected with SVN 1.6 and 1.7 clients: in particular, no username or password is requested when checking out myrepo/trunk. However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check out any directory without supplying the credentials of a user who has access to the repository root. svn co https://our.server.com/svn/myrepo/trunk - Requires authentication with client 1.8.x but not with 1.6.x or 1.7.x svn list https://our.server.com/svn/myrepo/trunk - Works even with 1.8.1 svn list https://our.server.com/svn/myrepo - Requires auth, as expected The 1.8.x clients can successfully check out myrepo/trunk if a username and password are given, for a user with access to the repository root. I have so far been unable to reproduce this with a simplified test repository, so any hints as to where to look would be much appreciated. The following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.6.18 (OS X): xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] OPTIONS /svn/myrepo/trunk HTTP/1.1 200 197 [...] /svn/myrepo/!svn/vcc/default HTTP/1.1 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1 207 479 And the following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows 7): xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] OPTIONS /svn/myrepo/trunk HTTP/1.1 200 197 [...] xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] PROPFIND /svn/myrepo/!svn/bc/123 HTTP/1.1 401 483 It should be 403 Forbidden, not 401 Unauthorized. Looks like some issue with server configuration. It appears that the 1.8.1 client requests /svn/myrepo/!svn/bc/123, to which access is denied (401), whereas client 1.6.18 only ever requests /svn/myrepo/!svn/bc/123/trunk, to which access is granted. Most likely it is some problem with inherited properties feature implemented in Subversion 1.8. The issue doesn't reproduces with server configured for non-anonymous access: the server returns 401 Forbidden for PROPFIND request on repository root and handled properly by Subversion 1.8 client. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Tue, Aug 20, 2013 at 12:20 PM, valentijnschol...@gmail.com wrote: On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: I did not find a solution however I wrote an monitor application that checks if the httpd.exe process hits 100%, if so I KILL the process and CollabNet then restarts another instance. Is it something you'd like to share? I used ProcDump to create a dump when the process went to 100%. Would it be usefull to post it here? Could you post just call stack here? -- Ivan Zhakov
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Tue, Aug 20, 2013 at 2:05 PM, valentijnschol...@gmail.com wrote: On Tuesday, August 20, 2013 10:47:22 AM UTC+2, Ivan Zhakov wrote: On Tue, Aug 20, 2013 at 12:20 PM, valentij...@gmail.com wrote: On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: I did not find a solution however I wrote an monitor application that checks if the httpd.exe process hits 100%, if so I KILL the process and CollabNet then restarts another instance. Last night the problem occurred again, this time I had debug logging enabled for apache, and left it running for a while. Error log shows last succesfull requests at 19:51. Some hours later all apache threads are busy, as reported in the error log: Mon Aug 19 19:51:49.378688 2013] [authz_core:debug] [pid 568:tid 932] mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization result of RequireAny: denied (no authenticated user yet) [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization result of Require valid-user : denied (no authenticated user yet) [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization result of RequireAny: denied (no authenticated user yet) [Mon Aug 19 19:51:51.660084 2013] [authnz_ldap:debug] [pid 568:tid 932] mod_authnz_ldap.c(500): [client 172.17.1.15:2283] AH01691: auth_ldap authenticate: using URL ldap://172.17.1.1:3268/DC=isaac,DC=local?sAMAccountName?sub [Mon Aug 19 21:06:55.298940 2013] [mpm_winnt:error] [pid 568:tid 964] AH00326: Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting As I replied you privately I cannot investigate provided dumps because you're using CollabNet distribution and I don't have access to PDB files required for crash dumps debugging. But from what I see process is stuck in libaprutil-1.dll!7489fc50(), given the last message in debug log is auth_ldap authenticate: using URL it most likely problem with communication with LDAP server (ldap protocol implemented in libapr-util). It could be misconfiguration or bug in libapr-util. -- Ivan Zhakov
Re: Cannot check out public directory with client 1.8.x without access to repo root
On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida marktsuch...@gmail.com wrote: Hello, I'm having an issue with our partially-public SVN repository. The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS. Our repository (let's call it myrepo) allows public read access (* = r) to myrepo/trunk, but not to myrepo/ (the root). There is also a directory myrepo/trunk/secret to which only specific users have access to. Everything has been working as expected with SVN 1.6 and 1.7 clients: in particular, no username or password is requested when checking out myrepo/trunk. However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check out any directory without supplying the credentials of a user who has access to the repository root. svn co https://our.server.com/svn/myrepo/trunk - Requires authentication with client 1.8.x but not with 1.6.x or 1.7.x svn list https://our.server.com/svn/myrepo/trunk - Works even with 1.8.1 svn list https://our.server.com/svn/myrepo - Requires auth, as expected The 1.8.x clients can successfully check out myrepo/trunk if a username and password are given, for a user with access to the repository root. I have so far been unable to reproduce this with a simplified test repository, so any hints as to where to look would be much appreciated. The following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.6.18 (OS X): xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] OPTIONS /svn/myrepo/trunk HTTP/1.1 200 197 [...] /svn/myrepo/!svn/vcc/default HTTP/1.1 207 420 xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] PROPFIND /svn/myrepo/!svn/bln/123 HTTP/1.1 207 479 And the following is the section of ssl_access_log produced by checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows 7): xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] OPTIONS /svn/myrepo/trunk HTTP/1.1 200 197 [...] xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] PROPFIND /svn/myrepo/!svn/bc/123 HTTP/1.1 401 483 It appears that the 1.8.1 client requests /svn/myrepo/!svn/bc/123, to which access is denied (401), whereas client 1.6.18 only ever requests /svn/myrepo/!svn/bc/123/trunk, to which access is granted. Most likely it is some problem with inherited properties feature implemented in Subversion 1.8. @Paul: Do you have any ideas? -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Issue 4039
On Mon, Aug 19, 2013 at 2:04 AM, Johan Corveleyn jcor...@gmail.com wrote: On Fri, Aug 16, 2013 at 8:31 PM, Angelo Tavares ang...@mega.com.br wrote: Good Morning You have a preview release of this fix, or if it will be developed? http://subversion.tigris.org/issues/show_bug.cgi?id=4039 The issue is: Add support for windows substed-drives The last comment in the issue tracker says: Reading symlinks on Windows Vista and later implemented in r1501251 on trunk. So probably this issue also fixed. So it sounds like it's not fixed in 1.8, but possibly fixed in trunk (i.e. the future 1.9 version). I'm not sure if this bugfix is at all backportable to 1.8, or if you'll have to wait for 1.9. Maybe someone else can comment (otherwise: go ahead and ask the can it be backported question in the issue tracker). (@Ivan: maybe the issue needs to be marked fixed in the issue tracker, if your last comment is correct). Johan, Issue 4039 missing details what is not working in users case. There is no reproduction case or something. Bert pointed the most likely users want to create SUBST drive for part of working. This case is not solved by my fix. And most likely never be fixed, so issue should be closed with WONTFIX or BYDESIGN. Angelo: what is not working in your case? -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Cope with IPv6
On Tue, Aug 13, 2013 at 12:52 PM, Okabayashi, Hirotsugu hirotsugu.okabaya...@jp.sony.com wrote: Dear Daniel, Thank you for your reply and I'm sorry to be late. -Only with IPv6, the Operating system handle the authentication. What does this mean? Sorry, let me explain about that in detail. With IPv4, TSVN displays TSVN's authentication window. With IPv6, however, TSVN displays Windows's authentication window(Windows Security Window) instead of TSVN's authentication window. TSVN displays Windows's authentication window when it tries to get list of repositories using Windows API, not Subversion libraries. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: How to change paths on an external file without a full update --depth infinity?
On Sun, Aug 11, 2013 at 8:54 PM, Ben Reser bre...@apache.org wrote: On Sun, Aug 11, 2013 at 3:24 AM, Johan Corveleyn jcor...@gmail.com wrote: I'm cc'ing Ben Reser (who has the above issue assigned to him) and Ivan Zhakov (who recenty wrote a patch for this). Perhaps they can shed some light on the current state of RA session caching. As far as I remember from discussions during the Berlin Hackathon, this was deemed too risky for 1.8, but perhaps within scope for 1.9. It's on my todo to review Ivan's patch. It seems like the best short term solution and is basically what I had already intended to do. My 'reuse-ra-session' branch is not complete yet. I'm going to finish it after fixing most critical svn 1.8 issues. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: svn client 1.8.1: Tries to log-in forever, hammering the server, eating memory and cpu
On Thu, Aug 8, 2013 at 12:36 PM, Stefan Sperling s...@elego.de wrote: On Thu, Aug 08, 2013 at 10:18:42AM +0200, Elias Gerber wrote: Since svn 1.8.x we experience the following: Clients that are part of the domain can log in without any problems. Clients that are not part of the domain try to log-in forever using the local account. The server rejects those credentials - it only knows about domain-users, not about local users. The client does not stop to log in then, but tries forever: At the server we see thousands of rejected log-in requests, at the client we see that it uses one core of the cpu 100% and eats more and more memory and never (? - I killed it when it reached more than one Gigabyte of memory) stops. My guess would be this issue in serf: http://code.google.com/p/serf/issues/detail?id=77 The 1.7 client uses neon instead of serf and optionally supports serf, but not many people used serf with 1.7 clients. Support for neon has been removed as of 1.8. The serf developers are working hard on issues that pop up now that people are actually using it. This is definitely serf issue 77. Issue should be fixed in r2112. And most likely will be backported to next serf 1.3.x release. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: internal error while updating sparse working copy (SVN 1.8.1)
On Fri, Jul 26, 2013 at 7:23 PM, David Lombardi david.lomba...@mortara.com wrote: The message was reported by TortoiseSVN during the update of a sparse working copy (while downloading to the WC several files/MB). OS: XP SP3 SVN Server: v1.7.8 Tortoise/SVN client 1.8.1 I repeated the operation after cleaning up the WC and it completed successfully. In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.1\ext\subversion\subversion\libsvn_ra_serf\util.c' line 1644: internal malfunction The issue most likely fixed by r1503318: [[[ ra_serf: Do not retry HTTP requests if we started to parse them. There is absolutely no guarantee that REPORT or PROPFIND responses will be equal for every request. Especially with taking to account hash randomization. ]]] Revision is nominated for backport and should be available in Subversion 1.8.2. [1] http://svn.apache.org/r1503318 -- Ivan Zhakov
Re: Windows junctions are not supported in Subversion 1.8.0 anymore
On Thu, Jul 25, 2013 at 1:25 PM, Thorsten Schöning tschoen...@am-soft.de wrote: Hello, I'm working heavily with Windows junctions in my development environment, meaning that e.g. I check out a working copy in an Eclipse workspace using Subclipse and afterwards create a junction to my httpd cgi-bin directory. Please note that I do not link deeply into the working copy but create the junction to the working copy root. One example: The directory ...\Eclipse\Perl\some_project contains my working copy checked out using Subclipse, afterwards I manually create ...\httpd\cgi-bin\somewhere\some_project as a junction to the some_project folder in my Eclipse workspace. This allowed me to use Subclipse within Eclipse and TortoiseSVN in Windows Explorer depending on what I need to work on in my web application, which gets served by the current code base developed in Eclipse. This worked without any problems for years now with older versions of Subversion, but starting with 1.8.0 I get the following error: svn: E27: Symbolic links are not supported on this platform This is not bug 4383, my client doesn't crash, it simply shows me the error message. Besides that, the bug's status is still new, but the changelog for 1.8.1 mentioned it as fixed. http://subversion.tigris.org/issues/show_bug.cgi?id=4383 http://svn.apache.org/repos/asf/subversion/tags/1.8.1/CHANGES Reading symbolic links on Windows Vista and later is implemented on trunk in r1501251 [1]: [[[ Implement reading symbolic links on Windows Vista or later. This fix issues with working copies located in symlinked folders. ]]] Maybe it worth to backport this change to 1.8.x to fix reported issue? [1] http://svn.apache.org/r1501251 -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Memory cleanup / leakage
On Fri, Jun 21, 2013 at 4:48 PM, kai-uwe.schie...@hydrometer.de wrote:
Please add me to the answer list, cause I am not subscribed.
I am using the Binary Package of Subversion library Version 1.7.9 in my
software.
Everything works fine so far but a little memory leak I detected in my
tests. I am not shure if I use everything as I should. Maybe you can help
me.
I reduced the usage of the lib to the following:
Code start:
while(true)
{
apr_initialize();
apr_pool_initialize();
AFAIK it's not allowed to call apr_initialize() more than once per process.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: Crash during attempted dump of repository
On Tue, Dec 13, 2011 at 20:29, Mourrat, David (CA-CIB) david.mour...@ca-cib.com wrote: Hi all, I was trying to dump my repository with these results: E:\VoloxTmpC:\Program Files\VisualSVN Server\bin\svnadmin dump -r 19000:29950 E:\svn_repository_new E:\VoloxTmp\dump_new.svndump [...] Do you have an idea? Could you please try to run svnadmin command with memory caching disabled. I.e. E:\VoloxTmpC:\Program Files\VisualSVN Server\bin\svnadmin dump -r 19000:29950 -M 0 E:\svn_repository_new E:\VoloxTmp\dump_new.svndump -- Ivan Zhakov
Re: Downloading Link for SVN 1.7.1 Server
On Mon, Nov 14, 2011 at 18:21, Waseem Shahzad waseem.shah...@curemd.com wrote: I need to download SVN 1.7.1 Server for windows. Any link. http://www.visualsvn.com/downloads/ -- Ivan Zhakov
Re: update in 1.6.17 slower?
On Fri, Aug 19, 2011 at 03:27, Seth Daniel subversion@sethdaniel.org wrote: Hello, Recently I upgraded from 1.6.9 to 1.6.17. 'svn up' is very noticeably slower than it used to be. I didn't see anything in the CHANGES file about signficant 'update' changes so I was wondering if this was expected? With 1.6.9 I didn't turn off authz (even though I don't use it) but I thought maybe it was the problem with 1.6.17. No luck. (btw, I'm using Apache + https. I turned *off* authz using SVNPathAuthz off). checkout and other operations are very snappy. I am using default options when building subversion so I'm using neon. It's neon 0.25 (comes with Centos 5.4). It could be related to the following change in Subversion 1.6.15: [[ * filter unreadable paths for 'svn ls' and 'svn co' (r997026, -070, -474) ]] Log message for revision r997026 is: [[[ For issue #3709 (Inconsistency between svn list and svn checkout), teach the mod_dav_svn tree walker logic to authorize access to the paths it touches. * subversion/mod_dav_svn/repos.c (do_walk): Replace a decade-old TODO about checking authorization on a directory's children with, you know, code that checks authorization on a directory's children. ]]] -- Ivan Zhakov
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 12:34, Becker, Thomas thomas.bec...@torex.com wrote: Hi, I tried to list a repository served by Visual SVN 2.1.9 (Subversion 1.6.17, Apache 2.2.19) with a Windows 1.7 pre-release client downloaded from Collabnet (https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows ). With the “alpha” and “beta” clients I get the following error: svn.exe ls https://:8443/ svn: E175009: Unable to connect to a repository at URL 'https://:8443/' The URL for VisualSVN Server repositories should be like https:/xxx:8443/svn/. Please make sure that you are using correct URL to repository. -- Ivan Zhakov
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 13:37, Becker, Thomas thomas.bec...@torex.com wrote: Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas Could you please try to add explicit ServerName configuration directive to %VISUALSVN_SERVER%\conf\httpd-custom.conf file and restart the server: ServerName :8443 -- Ivan Zhakov
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 20:25, Ivan Zhakov i...@visualsvn.com wrote: On Tue, Jul 26, 2011 at 13:37, Becker, Thomas thomas.bec...@torex.com wrote: Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas Could you please try to add explicit ServerName configuration directive to %VISUALSVN_SERVER%\conf\httpd-custom.conf file and restart the server: ServerName :8443 I was able to reproduce the issue in my environment. It seems to be bug in ra_serf/serf code: it sets SNI hostname to 'hostname:port', while valid value is 'hostname' (without port). So currently there're two workaround possible: 1. Use neon as http-library on client 2. Use default HTTPS port (443) on server -- Ivan Zhakov
Re: 1.7 compatibility issue
On Tue, Jul 26, 2011 at 20:45, Ivan Zhakov i...@visualsvn.com wrote: On Tue, Jul 26, 2011 at 20:25, Ivan Zhakov i...@visualsvn.com wrote: On Tue, Jul 26, 2011 at 13:37, Becker, Thomas thomas.bec...@torex.com wrote: Yes, actually starts with svn. The URL looks like this: https://server:8443/svn/repository_name Regards, Thomas Could you please try to add explicit ServerName configuration directive to %VISUALSVN_SERVER%\conf\httpd-custom.conf file and restart the server: ServerName :8443 I was able to reproduce the issue in my environment. It seems to be bug in ra_serf/serf code: it sets SNI hostname to 'hostname:port', while valid value is 'hostname' (without port). So currently there're two workaround possible: 1. Use neon as http-library on client 2. Use default HTTPS port (443) on server Fixed in r1151177 and nominated for backport to 1.7.x. Thanks for bug report! -- Ivan Zhakov
