Re: 1.7.0-alpha1 feedback
On Tue, Jun 21, 2011 at 02:02:08AM +0200, Uwe Schuster wrote: > Stefan Sperling wrote: > > >Thanks for testing the alpha! > > Thanks for your feedback! > > >>1. Performance > > > >Can you set > > http-library=neon > >in the '[global]' section of your 'servers' configuration file > >and see if that helps? > > > >The checkout finishes within 2minutes for me (with neon, on OpenBSD, > >16mbit/s downstream). > > Yes this helps very much! > > 39 seconds and 6,82 MB instead of 30 min 27 s and 55,70 MB Right. So this is an issue with serf. None of the existing serf issues seem to match, though. Is there anything special about your setup, such as connecting through a proxy? > >>2. APR error on checkout > > > >This sounds like this known issue: > >http://subversion.tigris.org/issues/show_bug.cgi?id=3917 > > Yes that seems to be the same issue. Good! > >>3. Error when the URL is "different" from the actual URL > > > >I can reproduce this with the externals definition in your repository: > > > >svn: warning: W20: Error handling externals definition for > >'jcl/source/include/jedi': > >svn: warning: W17: > >'https://projectjedi.svn.sourceforge.net:443/svnroot/projectjedi/trunk/shared/include' > > isn't in the same repository as > >'https://projectjedi.svn.sourceforge.net/svnroot/projectjedi' > >Checked out revision 3547. > > > >This is definitely a bug. > >It works fine if the port (:443) is removed from the externals definition. > > Should I log this? I've already done so: http://subversion.tigris.org/issues/show_bug.cgi?id=3933
Re: 1.7.0-alpha1 feedback
Stefan Sperling wrote: Thanks for testing the alpha! Thanks for your feedback! 1. Performance Can you set http-library=neon in the '[global]' section of your 'servers' configuration file and see if that helps? The checkout finishes within 2minutes for me (with neon, on OpenBSD, 16mbit/s downstream). Yes this helps very much! 39 seconds and 6,82 MB instead of 30 min 27 s and 55,70 MB 2. APR error on checkout This sounds like this known issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3917 Yes that seems to be the same issue. 3. Error when the URL is "different" from the actual URL I can reproduce this with the externals definition in your repository: svn: warning: W20: Error handling externals definition for 'jcl/source/include/jedi': svn: warning: W17: 'https://projectjedi.svn.sourceforge.net:443/svnroot/projectjedi/trunk/shared/include' isn't in the same repository as 'https://projectjedi.svn.sourceforge.net/svnroot/projectjedi' Checked out revision 3547. This is definitely a bug. It works fine if the port (:443) is removed from the externals definition. Should I log this? -- Uwe Schuster http://sourceforge.net/projects/radstudioverins/ http://www.bitcommander.de/blog
Re: 1.7.0-alpha1 feedback
On Tue, Jun 21, 2011 at 01:09:31AM +0200, Uwe Schuster wrote: > Hi, > > I am new to this list and do usually look at the dev mailing list > with the web interface to get some information about the 1.7 > progress. I've noticed some problems with 1.7.0-alpha1 or better to > say the revision 1136035 DLLs from svn-1.7.0-dev-win32-r1136035.zip > and the Delphi client I am working on. Meanwhile I've installed TSVN > 1.6 and 1.6.99 in parallel and can repeat the issues and want to let > you know about the issues. I can't spend much time on looking if > these issues are already reported. Thanks for testing the alpha! > 1. Performance Can you set http-library=neon in the '[global]' section of your 'servers' configuration file and see if that helps? The checkout finishes within 2minutes for me (with neon, on OpenBSD, 16mbit/s downstream). > 2. APR error on checkout This sounds like this known issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3917 > 3. Error when the URL is "different" from the actual URL I can reproduce this with the externals definition in your repository: svn: warning: W20: Error handling externals definition for 'jcl/source/include/jedi': svn: warning: W17: 'https://projectjedi.svn.sourceforge.net:443/svnroot/projectjedi/trunk/shared/include' isn't in the same repository as 'https://projectjedi.svn.sourceforge.net/svnroot/projectjedi' Checked out revision 3547. This is definitely a bug. It works fine if the port (:443) is removed from the externals definition.
1.7.0-alpha1 feedback
Hi, I am new to this list and do usually look at the dev mailing list with the web interface to get some information about the 1.7 progress. I've noticed some problems with 1.7.0-alpha1 or better to say the revision 1136035 DLLs from svn-1.7.0-dev-win32-r1136035.zip and the Delphi client I am working on. Meanwhile I've installed TSVN 1.6 and 1.6.99 in parallel and can repeat the issues and want to let you know about the issues. I can't spend much time on looking if these issues are already reported. 1. Performance 2. APR error on checkout 3. Error when the URL is "different" from the actual URL 1. Performance When I do checkout one of the other projects I am working on I do see a huge performance difference between 1.6 and 1.7. The difference I do see is much bigger than the values in your performance wiki. The URL is https://jcl.svn.sourceforge.net/svnroot/jcl/trunk/jcl TSVN 1.6.16 (x64): 50 seconds (6,84 MB) TSVN 1.6.99, Build 21594 (x64): 30 min 27 s (55,70 MB) I do have a 6 MBit connection, am using Win 7 x64, 750 GB HDD and an old Core2 Conroe 6400. What I do see is that 1.7 jumps between folders I see this with 1.7 [...] Added: G:\svnwc17\source\common Added: G:\svnwc17\experts\useswizard\JclWin32Ex.txt text/plain Added: G:\svnwc17\experts\useswizard\JediUsesWizard.ini Added: G:\svnwc17\source\common\JclContainerIntf.pas [...] while I do see this with 1.6 [...] Added: G:\svnwc16\experts\useswizard\JclSysUtils.txt Added: G:\svnwc16\experts\useswizard\JclWin32Ex.txt Added: G:\svnwc16\experts\useswizard\JclEDI_UNEDIFACT_Ext.txt Added: G:\svnwc16\experts\useswizard\JclContainerIntf.txt Added: G:\svnwc16\experts\useswizard\JediUsesWizard.ini [...] 2. APR error on checkout When I checkout something from a private repo (Visual SVN 2.1.6) the checkout stops somewhen with an error with 1.7 in contrast to 1.6. TSVN tells me this error Error: Error retrieving REPORT (108): Unknown error When running Version Insight under the Debugger I got this error Project bds.exe raised exception class ESvnError with message 'Error retrieving REPORT (620019): APR does not understand this error code'. followed by Project bds.exe raised exception class EAccessViolation with message 'Access violation at address 6385F7C8 in module 'libsvn_ra-1.dll'. Read of address FEEEFF0A'. Unfortunately I can't provide you with the URL, because the content in the repo is confidential. 3. Error when the URL is "different" from the actual URL I do have a repo on a Visual SVN 2.1.6 server and it's root URL is https://Win7/svn Checking out https://localhost/svn/testing/trunk works, but https://localhost:443/svn/testing/trunk fails with 1.7 with the error 'https://localhost:443/svn/testing/trunk' isn't in the same repository as 'https://localhost/svn/testing' with 1.6 this works This is also a problem with the externals in the repo from 1. There I do get the error too 'https://projectjedi.svn.sourceforge.net:443/svnroot/projectjedi/trunk/shared/include' isn't in the same repository as 'https://projectjedi.svn.sourceforge.net/svnroot/projectjedi' -- Uwe Schuster http://sourceforge.net/projects/radstudioverins/ http://www.bitcommander.de/blog
FW: issue #3264 Regarding: http://subversion.tigris.org/issues/show_bug.cgi?id=3264
(I did not get any acceptance reply on this email. Hence resending it).
From: lakhi...@hotmail.com
To: users@subversion.apache.org
Subject: issue #3264
Date: Thu, 16 Jun 2011 15:41:34 -0700
I have some information on this issue.
http://subversion.tigris.org/issues/show_bug.cgi?id=3264
(Hoping we could get a fix for this. The workaround is not really okay for
automatic scripts).
Running svn client either from cli (cygwin) (or from gui: tortioise-svn) from
relatively slow VMs.
A relatively large repository is being checked out. VM is slow, and there are
lots of instances where
svn client TCP windows goes to zero, and then opens up again. (As against a
relatively fast client, where
such fluctuations were not seen). client setting: http-timeout = 1800. This
is from a cli/cygwin client:
wireshark capture: (last few packets) client
(172.17.37.63) and subversion server (10.74.40.232)
PKT#Time (seconds) SRC SSDST DS PROTO
LEN
-- - --
64459936.01842710.74.40.23280172.17.37.6350798HTTP
1434 Continuation or non-HTTP traffic
64460936.01842910.74.40.23280172.17.37.6350798HTTP
115Continuation or non-HTTP traffic
64461936.018441172.17.37.635079810.74.40.23280TCP54
50798 > 80 [ACK] Seq=6565 Ack=65979260 Win=20474 Len=0
64462938.661108172.17.37.635079810.74.40.23280TCP54
[TCP Window Update] 50798 > 80 [ACK] Seq=6565 Ack=65979260 Win=65535 Len=0
64463940.355624172.17.37.635079810.74.40.23280TCP54
50798 > 80 [FIN, ACK] Seq=6565 Ack=65979260 Win=65535 Len=0
--
Client bails out saying:
svn: REPORT of '/xxx/yyy/!svn/vcc/default': Could not read response body:
connection was closed by server (http://subversion.xx.com)
Clearly, this client is not waiting enough for the server to send more data.
There is a delay of about half a second where nothing is received from the
server. After the second ACK from client (172.17.37.63) to subversion server
(10.74.40.232) the next packet is has a FIN..! Server has been silent
for approximately 4 seconds in the end --whether it reset or is just preparing
data to send I can not say, though server apache error-logs have errors showing
it could not write base64 data, but that could be the result of this client
sending a FIN. After all, server did not close the TCP connection.
In some prior runs, where I captured the whole session, the gap between server'
last data packet and svn client sending a FIN is much smaller (0.05 seconds,
approx):
33494647.94420810.74.40.23280172.17.37.6350167HTTP
883Continuation or non-HTTP traffic
33495647.944218172.17.37.635016710.74.40.23280TCP54
50167 > 80 [ACK] Seq=6564 Ack=50422857 Win=24686 Len=0
33496647.948777172.17.37.635016710.74.40.23280TCP54
[TCP Window Update] 50167 > 80 [ACK] Seq=6564 Ack=50422857 Win=28158 Len=0
33497647.949267172.17.37.635016710.74.40.23280TCP54
[TCP Window Update] 50167 > 80 [ACK] Seq=6564 Ack=50422857 Win=65535 Len=0
33498647.996754172.17.37.635016710.74.40.23280TCP54
50167 > 80 [FIN, ACK] Seq=6564 Ack=50422857 Win=65535 Len=0
bash-3.2$ svn --version
svn, version 1.6.11 (r934486)
compiled Apr 19 2010, 12:23:49
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- 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.
- handles 'http' scheme
- handles 'https' scheme
Thank you.
Re: [perl bindings] Bizarre copy of UNKNOWN in subroutine
On Mon, Jun 20, 2011 at 09:54:12AM -0400, Stéphane Gaudreault wrote: > Le 19 juin 2011 13:53:12, Stefan Sperling a écrit : > > On Sun, Jun 19, 2011 at 07:43:31PM +0200, Otto Allmendinger wrote: > > > So does this qualify as a proper bug? Can I add this to the issue > > > tracker? > > > > Yes, please add it. > > > > Someone will need to pin down where the problem is coming from. > > Is it SWIG? Is it Perl? Is it Subversion? > > > > Can you try to reproduce the problem with an earlier version of > > SWIG and/or Perl? > > Hi, > > We think that only 32 bits systems are affected by this bug because > > cd subversion-1.6.17/subversion/bindings/swig/perl/native; make test > > fails on i686, but works on x86_64[1]. > > We have that problem with either swig 2.0.3 or 2.0.4. We had no problem with > perl v5.12.3. The problem was noticed after the upgrade to v5.14.0. Someone > suggested that the problem could be related to the use of 64bits offset by > perl > [2]. > > Regards, > > Stéphane Gaudreault > > [1] https://bugs.archlinux.org/task/24540 > [2] http://www.gossamer-threads.com/lists/perl/porters/263222 Are you sure the test failures referenced in [2] are related to the "bizarre copy of UNKNOWN" problem? I don't see that error appearing in [2]. But if your are sure it's related, the link at [2] clearly explains that perl and extensions were compiled in an incompatible way: "I doubt there's anything crucial about the particular flag, but rather it's the fact that you're building extensions using flags that give you code that is binary incompatible with the perl binary it's being built against." "With options like -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64' used to build Perl but dropped when testing extension building, you could be getting a different and incompatible stat structure or other binary incompatible differences between the extension and the Perl core. " Which is right. Any software that shares data structures needs the data structures to be compatible. Else it crashes and whatnot. So is this "bizarre copy of UNKNOWN" problem showing anywhere else than Debian and Arch Linux? Maybe it's a problem with how these distributions compile perl and related software? Maybe Perl is compiled with support for large files but Subversion is not, or something like that?
Re: SVNNotify - not setting date in header
Miguel Almeida wrote on Mon, Jun 20, 2011 at 15:02:27 +0100: > I tried adding the following, but with no success (I must be passing > the date wrongly): > --add-header date=`date -R` --add-header Date="`date -R`" FWIW, 'date -R' is not portable; I think the portable version is LC_ALL=C date +"%a, %d %b %Y %H:%M:%S %z" > > Any help appreciated, > > > Miguel Almeida >
SVNNotify - not setting date in header
Hi, I was trying out svnnotify with the following code: #/usr/bin/svnnotify -r $REV -C -d -H HTML::ColorDiff -p $REPOS -t myEmail --from fromEmail \ --smtp myserver\ --smtp-user credential \ --smtp-password pw However, this script doesn't add a Date field to the email header, yielding this warning in my server: Jun 20 14:31:59 webservices amavis[13470]: (13470-12) Passed BAD-HEADER, LOCAL [192.168.10.103] [192.168.10.103] -> , quarantine: a/badh-asfzLX6WFNfd, mail_id: asfzLX6WFNfd, Hits: -0.319, size: 5193, queued_as: D1A6012EA182, 560 ms Has anyone else gotten this error? I tried adding the following, but with no success (I must be passing the date wrongly): --add-header date=`date -R` Any help appreciated, Miguel Almeida
Re: [perl bindings] Bizarre copy of UNKNOWN in subroutine
Le 19 juin 2011 13:53:12, Stefan Sperling a écrit : > On Sun, Jun 19, 2011 at 07:43:31PM +0200, Otto Allmendinger wrote: > > So does this qualify as a proper bug? Can I add this to the issue > > tracker? > > Yes, please add it. > > Someone will need to pin down where the problem is coming from. > Is it SWIG? Is it Perl? Is it Subversion? > > Can you try to reproduce the problem with an earlier version of > SWIG and/or Perl? Hi, We think that only 32 bits systems are affected by this bug because cd subversion-1.6.17/subversion/bindings/swig/perl/native; make test fails on i686, but works on x86_64[1]. We have that problem with either swig 2.0.3 or 2.0.4. We had no problem with perl v5.12.3. The problem was noticed after the upgrade to v5.14.0. Someone suggested that the problem could be related to the use of 64bits offset by perl [2]. Regards, Stéphane Gaudreault [1] https://bugs.archlinux.org/task/24540 [2] http://www.gossamer-threads.com/lists/perl/porters/263222
RE: Custom diff3 command
You will need to write a wrapper script to perform this. Start here http://svnbook.red-bean.com/en/1.5/svn.advanced.externaldifftools.html and configure your subversion to kick off your custom wrapper. Manipulate the passed in args as you want them and output them to your diff prog. Hope this sets you on the right track. Adam D From: Arpe, Kevin C [mailto:kevin.c.a...@jpmorgan.com] Sent: 20 June 2011 04:31 To: users@subversion.apache.org Subject: Custom diff3 command Hi, I am a Subversion command-line tools user on Windows XP. Version string = svn, version 1.6.12 (r955767) / compiled Jun 21 2010, 16:00:59 I wrote my own diff3 command batch file. We use it on my team to redirect merges thru KDiff3. I have noticed the argument list is not very descriptive. I will follow GNU diff3 terminology: MYFILE, OLDFILE, YOURFILE. Here are the arguments that my diff3 batch files receives: (These arguments seem to follow the GNU diff3 argument style.) 1) -E 2) -m 3) -L 4) .working 5) -L 6) .merge-left.rOLD_REVISION 7) -L 8) .merge-right.rYOUR_REVISION 9) /full/path/to/MYFILE 10) /full/path/to/OLDFILE 11) /full/path/to/YOURFILE In the above argument list, the -L values are not descriptive enough. Can we add the filename as a prefix? Example: .working -> MYFILE.working Such that, if MYFILE = biglib.c, then .working -> biglib.c.working Many thanks, Kevin Connor Arpe Hongkong This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. PLEASE NOTE THAT WE HAVE MOVED. Our new address is 4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 1QS. Our new telephone number is +44 (0) 20 3535 8300. This e-mail and its attachments are confidential. If you are not the intended recipient of this e-mail message, please telephone or e-mail us immediately, delete this message from your system and do not read, copy, distribute, disclose or otherwise use this e-mail message and any attachments. Although RI3K believes this e-mail and any attachments to be free of any virus or other defect which may affect your computer, it is the responsibility of the recipient to ensure that it is virus free and RI3K does not accept any responsibility for any loss or damage in any way from its use. RI3K Limited is a company registered in England no: 3909745. Registered office 4th Floor, Dashwood House, 69 Old Broad Street, London, EC2M 1QS. VAT registration no: 769 0192 07
Re: xml-aware diff tools?
Try a visual diff tool such as Araxis Merge, Beyond Compare, etc.? On Mon, Jun 20, 2011 at 8:24 AM, Les Mikesell wrote: > Are there any tools that would work with subversion to view xml file diffs > in a more meaningful way than just the changed lines? > > -- > Les Mikesell > lesmikes...@gmail.com > >
xml-aware diff tools?
Are there any tools that would work with subversion to view xml file diffs in a more meaningful way than just the changed lines? -- Les Mikesell lesmikes...@gmail.com
