AW: svn commit: r1156375 - /subversion/branches/fs-py/subversion/python/svn/fs.py
Hi, Von: Greg Stein [mailto:gst...@gmail.com] On Wed, Aug 10, 2011 at 19:15, Branko Čibej br...@xbc.nu wrote: ... Explicit management of rare resources is no bad thing. The with statement was introduced specifically to do away with the flaky, three times longer try-except-else that would otherwise be necessary in order to guarantee that file objects are closed. With the prior constructions: open(foo).read() open(foo, 'w').write(bar) Constructs like this never worked reliable in alternative python implementations. And now, as IronPython has a working cTypes implementation, maybe that is the way to provide subversion support for IronPython. Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: Significant checkout performance degradation between 1.6.1 and 1.7b2
Thanks, Philip. I've tried to build a repository with just the latest trunk or my repository, to make sure we're as much in sync as possible, but it's still taking just about as long as before to do a checkout. Seems to be a Windows/Linux issue. I googled a bit and from what I found, it's either an inherent problem or some config issue that's going to take ages to diagnose. Oh well, something for another day. Regards, Michael From: Philip Martin [philip.mar...@wandisco.com] Sent: Thursday, August 11, 2011 00:10 To: Ketting, Michael Cc: dev@subversion.apache.org Subject: Re: Significant checkout performance degradation between 1.6.1 and 1.7b2 Ketting, Michael michael.kett...@rubicon.eu writes: Those are interesting numbers, Philip. When you say local repository, you're talking about localhost, but still using HTTP? I'm curious about the actual timing since you got the same ratio as long as you used a physical disk but had an overall speed improvement by a factor of eight. Is that Linux or localhost? Using HTTP with both Apache and the client running on my desktop machine (which is not powerful by todays standards). I get much the same speed checking out on to my Linux laptop over my LAN from Apache running on my desktop. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
RE: Significant checkout performance degradation between 1.6.1 and 1.7b2
Just a bit more information: I've now also tried the chekcout tests with other other big trunks in our company: One took 7min (svn 1.6) vs 9min (svn 1.7), the other 4min (svn 1.6) vs 6min (svn 1.7), so, both are slower but in the range also measured with the benchmarks. Looks like my own project really is the worst case scenario :) Regards, Michael From: Mark Phippard [markp...@gmail.com] Sent: Tuesday, August 09, 2011 17:05 To: Ketting, Michael Cc: dev@subversion.apache.org Subject: Re: Significant checkout performance degradation between 1.6.1 and 1.7b2 On Tue, Aug 9, 2011 at 8:07 AM, Mark Phippard markp...@gmail.commailto:markp...@gmail.com wrote: Is this via http? Given that export is slower I'd be willing to bet the performance difference is from the new http client library - serf. It is typically slower than Neon. Try switching to neon and run it again. I updated to the latest Beta of TortoiseSVN and it looks to me like they have changed the default HTTP client to Neon already. So unless you have specifically made serf the default client in your servers file it is not likely that this is your problem. I developed a set of open-source benchmarks to measure Subversion performance that you can get here: https://ctf.open.collab.net/sf/sfmain/do/viewProject/projects.csvn Perhaps you could set up the repository on your server and run the benchmarks using 1.6 and 1.7 to see what kind of results you see? When I run the tests I see considerable performance gain with 1.7. The FolderTests are probably the closes tests to your scenario. It will be easier to focus on any remaining performance issues if we can identify and measure them in an open and consistent manner so we can see progress and the impact of different changes. If these benchmarks do not show the same problems you see on your real code, then we need to add more benchmarks so that we can capture whatever the problem is. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Significant checkout performance degradation between 1.6.1 and 1.7b2
Can you tell a bit more about this 'worst case' working copy? Does it use svn:keywords in many places? What about svn:needs-lock? More svn:eol-style keywords than the other working copies? Bert From: Ketting, Michael [mailto:michael.kett...@rubicon.eu] Sent: donderdag 11 augustus 2011 10:54 To: dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Just a bit more information: I've now also tried the chekcout tests with other other big trunks in our company: One took 7min (svn 1.6) vs 9min (svn 1.7), the other 4min (svn 1.6) vs 6min (svn 1.7), so, both are slower but in the range also measured with the benchmarks. Looks like my own project really is the worst case scenario :) Regards, Michael _ From: Mark Phippard [markp...@gmail.com] Sent: Tuesday, August 09, 2011 17:05 To: Ketting, Michael Cc: dev@subversion.apache.org Subject: Re: Significant checkout performance degradation between 1.6.1 and 1.7b2 On Tue, Aug 9, 2011 at 8:07 AM, Mark Phippard markp...@gmail.com wrote: Is this via http? Given that export is slower I'd be willing to bet the performance difference is from the new http client library - serf. It is typically slower than Neon. Try switching to neon and run it again. I updated to the latest Beta of TortoiseSVN and it looks to me like they have changed the default HTTP client to Neon already. So unless you have specifically made serf the default client in your servers file it is not likely that this is your problem. I developed a set of open-source benchmarks to measure Subversion performance that you can get here: https://ctf.open.collab.net/sf/sfmain/do/viewProject/projects.csvn Perhaps you could set up the repository on your server and run the benchmarks using 1.6 and 1.7 to see what kind of results you see? When I run the tests I see considerable performance gain with 1.7. The FolderTests are probably the closes tests to your scenario. It will be easier to focus on any remaining performance issues if we can identify and measure them in an open and consistent manner so we can see progress and the impact of different changes. If these benchmarks do not show the same problems you see on your real code, then we need to add more benchmarks so that we can capture whatever the problem is. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: AW: svn commit: r1156375 - /subversion/branches/fs-py/subversion/python/svn/fs.py
On Aug 11, 2011 2:37 AM, Markus Schaber m.scha...@3s-software.com wrote: Hi, Von: Greg Stein [mailto:gst...@gmail.com] ... With the prior constructions: open(foo).read() open(foo, 'w').write(bar) Constructs like this never worked reliable in alternative python implementations. Yes. I do understand this thought, but the bindings simply are not intended for anything but CPython. If they somehow work for the other implementations, then I'd be completely surprised. And now, as IronPython has a working cTypes implementation, maybe that is the way to provide subversion support for IronPython. There is some experimental work using ctypesgen-based bindings. I did a small amount of work on them a couple years ago, but it could use more work. That would definitely be interesting work if it could make svn available to IronPython. Cheers, -g
RE: Significant checkout performance degradation between 1.6.1 and 1.7b2
Bert, you can access the repository here, in case you want to take a closer look: https://svn.re-motion.org/svn/Remotion/trunk/ What about svn:needs-lock? No, don't have any locked files. svn:eol-style Never heard of that one before. No, I've never set it. And as far as I know, it's not set in the other repositories, either. svn:keyword Mainly, it's a couple of mime-types for binary files. Maybe a 100? 200? Plus a few ignores. And probably some merge-info sprinkled across the trunk. Michael From: Bert Huijben [b...@qqmail.nl] Sent: Thursday, August 11, 2011 12:01 To: Ketting, Michael; dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Can you tell a bit more about this ‘worst case’ working copy? Does it use svn:keywords in many places? What about svn:needs-lock? More svn:eol-style keywords than the other working copies? Bert From: Ketting, Michael [mailto:michael.kett...@rubicon.eu] Sent: donderdag 11 augustus 2011 10:54 To: dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Just a bit more information: I've now also tried the chekcout tests with other other big trunks in our company: One took 7min (svn 1.6) vs 9min (svn 1.7), the other 4min (svn 1.6) vs 6min (svn 1.7), so, both are slower but in the range also measured with the benchmarks. Looks like my own project really is the worst case scenario :) Regards, Michael From: Mark Phippard [markp...@gmail.com] Sent: Tuesday, August 09, 2011 17:05 To: Ketting, Michael Cc: dev@subversion.apache.orgmailto:dev@subversion.apache.org Subject: Re: Significant checkout performance degradation between 1.6.1 and 1.7b2 On Tue, Aug 9, 2011 at 8:07 AM, Mark Phippard markp...@gmail.commailto:markp...@gmail.com wrote: Is this via http? Given that export is slower I'd be willing to bet the performance difference is from the new http client library - serf. It is typically slower than Neon. Try switching to neon and run it again. I updated to the latest Beta of TortoiseSVN and it looks to me like they have changed the default HTTP client to Neon already. So unless you have specifically made serf the default client in your servers file it is not likely that this is your problem. I developed a set of open-source benchmarks to measure Subversion performance that you can get here: https://ctf.open.collab.net/sf/sfmain/do/viewProject/projects.csvn Perhaps you could set up the repository on your server and run the benchmarks using 1.6 and 1.7 to see what kind of results you see? When I run the tests I see considerable performance gain with 1.7. The FolderTests are probably the closes tests to your scenario. It will be easier to focus on any remaining performance issues if we can identify and measure them in an open and consistent manner so we can see progress and the impact of different changes. If these benchmarks do not show the same problems you see on your real code, then we need to add more benchmarks so that we can capture whatever the problem is. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Significant checkout performance degradation between 1.6.1 and 1.7b2
A completely different question: Do you have a recent TortoiseSVN (TSvnCache.exe) running while checking out for those tests? I just ruined a testrun by accidentally enabling TSvnCache on it (by accessing a parent directory with the Windows explorer), and for the rest of the checkout TSvnCache took consistently 3 times more CPU than the checkout process by continuously calling 'svn status' on the same working copy. Bert From: Ketting, Michael [mailto:michael.kett...@rubicon.eu] Sent: donderdag 11 augustus 2011 12:13 To: dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Bert, you can access the repository here, in case you want to take a closer look: https://svn.re-motion.org/svn/Remotion/trunk/ What about svn:needs-lock? No, don't have any locked files. svn:eol-style Never heard of that one before. No, I've never set it. And as far as I know, it's not set in the other repositories, either. svn:keyword Mainly, it's a couple of mime-types for binary files. Maybe a 100? 200? Plus a few ignores. And probably some merge-info sprinkled across the trunk. Michael _ From: Bert Huijben [b...@qqmail.nl] Sent: Thursday, August 11, 2011 12:01 To: Ketting, Michael; dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Can you tell a bit more about this 'worst case' working copy? Does it use svn:keywords in many places? What about svn:needs-lock? More svn:eol-style keywords than the other working copies? Bert From: Ketting, Michael [mailto:michael.kett...@rubicon.eu] Sent: donderdag 11 augustus 2011 10:54 To: dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Just a bit more information: I've now also tried the chekcout tests with other other big trunks in our company: One took 7min (svn 1.6) vs 9min (svn 1.7), the other 4min (svn 1.6) vs 6min (svn 1.7), so, both are slower but in the range also measured with the benchmarks. Looks like my own project really is the worst case scenario :) Regards, Michael _ From: Mark Phippard [markp...@gmail.com] Sent: Tuesday, August 09, 2011 17:05 To: Ketting, Michael Cc: dev@subversion.apache.org Subject: Re: Significant checkout performance degradation between 1.6.1 and 1.7b2 On Tue, Aug 9, 2011 at 8:07 AM, Mark Phippard markp...@gmail.com wrote: Is this via http? Given that export is slower I'd be willing to bet the performance difference is from the new http client library - serf. It is typically slower than Neon. Try switching to neon and run it again. I updated to the latest Beta of TortoiseSVN and it looks to me like they have changed the default HTTP client to Neon already. So unless you have specifically made serf the default client in your servers file it is not likely that this is your problem. I developed a set of open-source benchmarks to measure Subversion performance that you can get here: https://ctf.open.collab.net/sf/sfmain/do/viewProject/projects.csvn Perhaps you could set up the repository on your server and run the benchmarks using 1.6 and 1.7 to see what kind of results you see? When I run the tests I see considerable performance gain with 1.7. The FolderTests are probably the closes tests to your scenario. It will be easier to focus on any remaining performance issues if we can identify and measure them in an open and consistent manner so we can see progress and the impact of different changes. If these benchmarks do not show the same problems you see on your real code, then we need to add more benchmarks so that we can capture whatever the problem is. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Significant checkout performance degradation between 1.6.1 and 1.7b2
Hi Bert! No, that wasn't running. And just the make sure, I redid my checkout tests, closed all explorer windows and checked with TaskManager. Got the same timing results as before. Regards, Michael From: Bert Huijben [b...@qqmail.nl] Sent: Thursday, August 11, 2011 12:52 To: Ketting, Michael; dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 A completely different question: Do you have a recent TortoiseSVN (TSvnCache.exe) running while checking out for those tests? I just ruined a testrun by accidentally enabling TSvnCache on it (by accessing a parent directory with the Windows explorer), and for the rest of the checkout TSvnCache took consistently 3 times more CPU than the checkout process by continuously calling ‘svn status’ on the same working copy. Bert From: Ketting, Michael [mailto:michael.kett...@rubicon.eu] Sent: donderdag 11 augustus 2011 12:13 To: dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Bert, you can access the repository here, in case you want to take a closer look: https://svn.re-motion.org/svn/Remotion/trunk/ What about svn:needs-lock? No, don't have any locked files. svn:eol-style Never heard of that one before. No, I've never set it. And as far as I know, it's not set in the other repositories, either. svn:keyword Mainly, it's a couple of mime-types for binary files. Maybe a 100? 200? Plus a few ignores. And probably some merge-info sprinkled across the trunk. Michael From: Bert Huijben [b...@qqmail.nl] Sent: Thursday, August 11, 2011 12:01 To: Ketting, Michael; dev@subversion.apache.orgmailto:dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Can you tell a bit more about this ‘worst case’ working copy? Does it use svn:keywords in many places? What about svn:needs-lock? More svn:eol-style keywords than the other working copies? Bert From: Ketting, Michael [mailto:michael.kett...@rubicon.eu]mailto:[mailto:michael.kett...@rubicon.eu] Sent: donderdag 11 augustus 2011 10:54 To: dev@subversion.apache.orgmailto:dev@subversion.apache.org Subject: RE: Significant checkout performance degradation between 1.6.1 and 1.7b2 Just a bit more information: I've now also tried the chekcout tests with other other big trunks in our company: One took 7min (svn 1.6) vs 9min (svn 1.7), the other 4min (svn 1.6) vs 6min (svn 1.7), so, both are slower but in the range also measured with the benchmarks. Looks like my own project really is the worst case scenario :) Regards, Michael From: Mark Phippard [markp...@gmail.com] Sent: Tuesday, August 09, 2011 17:05 To: Ketting, Michael Cc: dev@subversion.apache.orgmailto:dev@subversion.apache.org Subject: Re: Significant checkout performance degradation between 1.6.1 and 1.7b2 On Tue, Aug 9, 2011 at 8:07 AM, Mark Phippard markp...@gmail.commailto:markp...@gmail.com wrote: Is this via http? Given that export is slower I'd be willing to bet the performance difference is from the new http client library - serf. It is typically slower than Neon. Try switching to neon and run it again. I updated to the latest Beta of TortoiseSVN and it looks to me like they have changed the default HTTP client to Neon already. So unless you have specifically made serf the default client in your servers file it is not likely that this is your problem. I developed a set of open-source benchmarks to measure Subversion performance that you can get here: https://ctf.open.collab.net/sf/sfmain/do/viewProject/projects.csvn Perhaps you could set up the repository on your server and run the benchmarks using 1.6 and 1.7 to see what kind of results you see? When I run the tests I see considerable performance gain with 1.7. The FolderTests are probably the closes tests to your scenario. It will be easier to focus on any remaining performance issues if we can identify and measure them in an open and consistent manner so we can see progress and the impact of different changes. If these benchmarks do not show the same problems you see on your real code, then we need to add more benchmarks so that we can capture whatever the problem is. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
I'm using gcc. The default in the makefile. I think RHEL may have come with two different gcc, a 3 series and a 4 series. What version does 'gcc -v' show? 3.4.6 It would be good to confirm that at runtime you really are using the version of libapr you compiled, run ldd on the svn executable. If it wasn't, changing the optimization level shouldn't have made a difference. That being said, ldd reports that I am using the correct version. libapr-1.so.0 = /cos/home/ryttingm/local/lib/libapr-1.so.0 (0x002a967b5000) -Mike
RE: Problems compiling 1.7.0 on redhat el4 64bit
No luck with that option, still crashing. -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: Wednesday, August 10, 2011 4:20 PM To: RYTTING,MICHAEL (A-ColSprings,ex1) Cc: markp...@gmail.com; dev@subversion.apache.org; us...@subversion.apache.org Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit Philip Martin philip.mar...@wandisco.com writes: michael_rytt...@agilent.com writes: If I disable optimizations by doing make CFLAGS=-O0 the program no longer crashes. That suggests it could be a compiler bug. The other flag you could try is to enable optimisation but to use -fno-strict-aliasing. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
Re: Significant checkout performance degradation between 1.6.1 and 1.7b2
On Wed, Aug 10, 2011 at 2:02 PM, Ketting, Michael michael.kett...@rubicon.eu wrote: Our repository is open source, so, in case you believe it helps with benchmarking/finding the bottleneck, you're welcome to exporting the trunk ( https://svn.re-motion.org/svn/Remotion/trunk/) and creating a new benchmark repository. Am I correct in my assumption that building a new repository based only on the latest revision of the trunk would result in similar performance figures given it appears to be a client related issue? I am doing some testing with your repository. I get similar times as you do when using your repository from a Windows client. However, every time I checkout your repository using 1.6.17 it runs for about 5 minutes but always ends in failure: svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file 'test1\Remotion\Data\UnitTests\DomainObjects\Core\Mapping\TestDomain\Validation\Integration\NotSupportedRelations\BidirectionalRelation_RelatedObjectTypeDoesNotMatchOppositeProperty_BelowInheritanceRoot\.svn\tmp\text-base\InvalidRelationClass1.cs.svn-base': The system cannot find the path specified. So I have no idea if the checkout is only half complete. SVN 1.7 runs to completion but takes about 11 minutes. I am not sure why you do not get this same error, but I assume you are looking for it. Thanks Mark Phippard http://markphip.blogspot.com/
Re: Significant checkout performance degradation between 1.6.1 and 1.7b2
On Thu, Aug 11, 2011 at 11:45 AM, Mark Phippard markp...@gmail.com wrote: On Wed, Aug 10, 2011 at 2:02 PM, Ketting, Michael michael.kett...@rubicon.eu wrote: Our repository is open source, so, in case you believe it helps with benchmarking/finding the bottleneck, you're welcome to exporting the trunk ( https://svn.re-motion.org/svn/Remotion/trunk/) and creating a new benchmark repository. Am I correct in my assumption that building a new repository based only on the latest revision of the trunk would result in similar performance figures given it appears to be a client related issue? I am doing some testing with your repository. I get similar times as you do when using your repository from a Windows client. However, every time I checkout your repository using 1.6.17 it runs for about 5 minutes but always ends in failure: svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file 'test1\Remotion\Data\UnitTests\DomainObjects\Core\Mapping\TestDomain\Validation\Integration\NotSupportedRelations\BidirectionalRelation_RelatedObjectTypeDoesNotMatchOppositeProperty_BelowInheritanceRoot\.svn\tmp\text-base\InvalidRelationClass1.cs.svn-base': The system cannot find the path specified. I thought this might be an A/V problem, so I moved to a Win2k8 server that does not have any A/V installed. I got the same problem which made me realize it was the problem with max path length that has been addressed in 1.7. I re-ran the checkout using an absolute path so that 1.6 would run to completion. I got some odd results in that it all ran really fast: SVN 1.6.17 = 3:03 SVN 1.7-b3 = 2:40 So using 1.7 it was faster for me. I do not understand how these checkout times got so fast though. I checked the size of the working copy and they were each about 290MB, so I assume they are complete. -- Thanks Mark Phippard http://markphip.blogspot.com/
RE: Significant checkout performance degradation between 1.6.1 and 1.7b2
Hi Mark! Yeah, I was just going to suggest the max path length issue but you beat me to it :) The runtime really does baffle me, though. The 1.6.17 sounds about right. OK, a minute faster than mine, but... I reran the test with a relative path for svn 1.7, just to make sure, but still takes as long as before, so I've got no idea what's causing it. I think it's also of note that Philip got the same factor on his Linux setup, although the total was an order of magnitude smaller. No idea what to make of that... Regards, Michael From: Mark Phippard [markp...@gmail.com] Sent: Thursday, August 11, 2011 18:13 To: Ketting, Michael Cc: dev@subversion.apache.org Subject: Re: Significant checkout performance degradation between 1.6.1 and 1.7b2 On Thu, Aug 11, 2011 at 11:45 AM, Mark Phippard markp...@gmail.commailto:markp...@gmail.com wrote: On Wed, Aug 10, 2011 at 2:02 PM, Ketting, Michael michael.kett...@rubicon.eumailto:michael.kett...@rubicon.eu wrote: Our repository is open source, so, in case you believe it helps with benchmarking/finding the bottleneck, you're welcome to exporting the trunk (https://svn.re-motion.org/svn/Remotion/trunk/) and creating a new benchmark repository. Am I correct in my assumption that building a new repository based only on the latest revision of the trunk would result in similar performance figures given it appears to be a client related issue? I am doing some testing with your repository. I get similar times as you do when using your repository from a Windows client. However, every time I checkout your repository using 1.6.17 it runs for about 5 minutes but always ends in failure: svn: Your .svn/tmp directory may be missing or corrupt; run 'svn cleanup' and try again svn: Can't open file 'test1\Remotion\Data\UnitTests\DomainObjects\Core\Mapping\TestDomain\Validation\Integration\NotSupportedRelations\BidirectionalRelation_RelatedObjectTypeDoesNotMatchOppositeProperty_BelowInheritanceRoot\.svn\tmp\text-base\InvalidRelationClass1.cs.svn-base': The system cannot find the path specified. I thought this might be an A/V problem, so I moved to a Win2k8 server that does not have any A/V installed. I got the same problem which made me realize it was the problem with max path length that has been addressed in 1.7. I re-ran the checkout using an absolute path so that 1.6 would run to completion. I got some odd results in that it all ran really fast: SVN 1.6.17 = 3:03 SVN 1.7-b3 = 2:40 So using 1.7 it was faster for me. I do not understand how these checkout times got so fast though. I checked the size of the working copy and they were each about 290MB, so I assume they are complete. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
On Aug 11, 2011, at 8:32 AM, michael_rytt...@agilent.com michael_rytt...@agilent.com wrote: No luck with that option, still crashing. Try running the process under valgrind to see if it finds anything. Blair
RE: svn commit: r1156756 - /subversion/trunk/subversion/libsvn_client/patch.c
-Original Message- From: s...@apache.org [mailto:s...@apache.org] Sent: donderdag 11 augustus 2011 21:29 To: comm...@subversion.apache.org Subject: svn commit: r1156756 - /subversion/trunk/subversion/libsvn_client/patch.c Author: stsp Date: Thu Aug 11 19:29:25 2011 New Revision: 1156756 URL: http://svn.apache.org/viewvc?rev=1156756view=rev Log: * subversion/libsvn_client/patch.c (resolve_target_path): Rename LOCAL_ABSPATH parameter to the more obvious WCROOT_ABSPATH. It is the absolute path of the working copy root. (choose_target_filename): Rename BASE_DIR parameter to WCROOT_ABSPATH for the same reason. Looking at the callers this argument is not necessary the real wcroot, but just the directory where the path is applied to. (svn_client_patch performs baton.abs_wc_path = wc_dir_abspath which is then used for wcroot_abspath for this function). As I don't think the working copy root is the only valid patch target, I think this argument should have a different name. Bert
moved-to and moved-from in status output
Hi stsp, check this WIP patch out, attached. (I've also appended a wild test script that runs all sorts of things. Reading its bottom-most output may suffice.) I'd prefer printing the paths relative to the current working dir instead of relative to the WC root (as this patch does now). Say there was an [[[ ~/wc$ svn mv x/alpha a/b/beta ]]] currently: [[[ ~/wc$ cd a/b/ ~/wc/a/b$ svn st A +beta moved from x/alpha ]]] (relative to WC_ROOT) rather: [[[ ~/wc/a/b$ svn st A +beta moved from ../../x/alpha ]]] but I haven't figured out whether there's code that does this already. And, to that end, I think those batons should rather pass abspaths (see comments in the code). What do you say? ~Neels First steps to show moved-to and moved-from in 'svn status'. * subversion/include/svn_client.h * subversion/include/svn_wc.h * subversion/libsvn_client/status.c (svn_client_status_dup): (svn_client__create_status): * subversion/libsvn_wc/status.c (assemble_status): (svn_wc_dup_status3): * subversion/svn/status.c (print_status): --This line, and those below, will be ignored-- conf: # dub:/home/neels/pat/.pat-base/config-default conf: http://archive.apache.org/dist/apr/apr-1.4.2.tar.bz2 conf: http://archive.apache.org/dist/apr/apr-util-1.3.9.tar.bz2 conf: http://www.sqlite.org/sqlite-3.6.23.1.tar.gz conf: http://archive.apache.org/dist/httpd/httpd-2.2.15.tar.bz2 conf: http://www.webdav.org/neon/neon-0.29.3.tar.gz conf: http://ftp2.de.freebsd.org/pub/FreeBSD/distfiles/bdb/db-4.8.30.tar.gz conf: ftp://ftp.fu-berlin.de/unix/gnu/libiconv/libiconv-1.13.1.tar.gz conf: fsfs conf: local Index: subversion/include/svn_client.h === --- subversion/include/svn_client.h (revision 1156828) +++ subversion/include/svn_client.h (working copy) @@ -2206,6 +2206,18 @@ typedef struct svn_client_status_t * to other data in future versions. */ const void *backwards_compatibility_baton; + /** Set to @c true if this file or directory is scheduled for + * addition-with-history that is part of an explicit move operation (or part + * of a subtree that is scheduled as such). + */ + /** Set to the path (relative to the working copy root) that this node was + * moved from, if this file or directory has been moved here locally. */ + const char *moved_from_relpath; + + /** Set to the path (relative to the working copy root) that this node was + * moved to, if this file or directory has been moved away locally. */ + const char *moved_to_relpath; + /* NOTE! Please update svn_client_status_dup() when adding new fields here. */ } svn_client_status_t; Index: subversion/include/svn_wc.h === --- subversion/include/svn_wc.h (revision 1156828) +++ subversion/include/svn_wc.h (working copy) @@ -3619,6 +3619,14 @@ typedef struct svn_wc_status3_t /** @} */ + /* Set to the move source path if this item has been explicitly moved here + * (path relative to the working copy root) */ + const char *moved_from_relpath; + + /* Set to the move destination path if this item has been explicitly moved + * away (path relative to the working copy root) */ + const char *moved_to_relpath; + /* NOTE! Please update svn_wc_dup_status3() when adding new fields here. */ } svn_wc_status3_t; Index: subversion/libsvn_client/status.c === --- subversion/libsvn_client/status.c (revision 1156828) +++ subversion/libsvn_client/status.c (working copy) @@ -563,6 +563,12 @@ svn_client_status_dup(const svn_client_s result_pool); } + if (status-moved_from_relpath) +st-moved_from_relpath = apr_pstrdup(result_pool, status-moved_from_relpath); + + if (status-moved_to_relpath) +st-moved_to_relpath = apr_pstrdup(result_pool, status-moved_to_relpath); + return st; } @@ -667,6 +673,9 @@ svn_client__create_status(svn_client_sta (*cst)-node_status = svn_wc_status_conflicted; } + (*cst)-moved_from_relpath = status-moved_from_relpath; + (*cst)-moved_to_relpath = status-moved_to_relpath; + return SVN_NO_ERROR; } Index: subversion/libsvn_wc/status.c === --- subversion/libsvn_wc/status.c (revision 1156828) +++ subversion/libsvn_wc/status.c (working copy) @@ -403,6 +403,8 @@ assemble_status(svn_wc_status3_t **statu const char *repos_relpath; const char *repos_root_url; const char *repos_uuid; + const char *moved_from_relpath = NULL; + const char *moved_to_relpath = NULL; svn_filesize_t filesize = (dirent (dirent-kind == svn_node_file)) ? dirent-filesize : SVN_INVALID_FILESIZE; @@ -608,6 +610,42 @@ assemble_status(svn_wc_status3_t **statu }
Apache Subversion 1.7.0-beta3 Released
I'm happy to announce the release of Apache Subversion 1.7.0-beta3. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#pre-releases The SHA1 checksums are: fdd22605c83ad601810e9cd980116ebcde45ef20 subversion-1.7.0-beta3.tar.gz 65c2d68522e3aac8870a81d942d9962bb5399ed3 subversion-1.7.0-beta3.tar.bz2 e4a9b4c97db74cb2931466a14311db10a6220039 subversion-1.7.0-beta3.zip PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.0-beta3.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.0-beta3.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.0-beta3.zip.asc For this release, the following people have provided PGP signatures: C. Michael Pilato [1024D/1706FD6E] with fingerprint: 20BF 14DC F02F 2730 7EA4 C7BB A241 06A9 1706 FD6E Paul T. Burba [1024D/53FCDC55] with fingerprint: E630 CF54 792C F913 B13C 32C5 D916 8930 53FC DC55 Julian Foad [1024D/353E25BC] with fingerprint: 6604 5A4B 43BC F994 5728 351F 33E4 353E 25BC Bert Huijben [1024D/9821F7B2] with fingerprint: 2017 F51A 2572 0E78 8827 5329 FCFD 6305 9821 F7B2 Hyrum K. Wright [1024D/4E24517C] with fingerprint: 3324 80DA 0F8C A37D AEE6 D084 0B03 AE6E 4E24 517C Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Sperling [1024D/F59D25F0] with fingerprint: B1CF 1060 A1E9 34D1 9E86 D6D6 E5D3 0273 F59D 25F0 Mark Phippard [1024D/035A96A9] with fingerprint: D315 89DB E1C1 E9BA D218 39FD 265D F8A0 035A 96A9 This is a pre-release for what will eventually become Apache Subversion 1.7.0. There may still be minor issues, but all known blocking issues have been fixed. A pre-release means the Subversion developers feel that this release is ready for widespread testing by the community. Please use it at your own risk, though we do encourage people to test this release thoroughly. Of particular note, please remember than persistent data, such as the working copy or repository formats may change before the final release, and there may not be an upgrade path from the pre-releases to the final. As a note to operating system distro packagers: while we wish to have this release candidate widely tested, we do not feel that it is ready for packaging and providing to end-users through a distro package system. Packaging a release candidate poses many problems, the biggest being that our policy lets us break compatibility between the release candidate and the final release, if we find something serious enough. Having many users depending on a release candidate through their distro would cause no end of pain and frustration that we do not want to have to deal with. However, if your distro has a branch that is clearly labeled as containing experimental and often broken software, and explicitly destined to consenting developers and integrators only, then we're okay with packaging the release candidate there. Just don't let it near the end users please. Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html You can find the list of changes between 1.7.0-beta3 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.0-beta3/CHANGES Questions, comments, and bug reports to us...@subversion.apache.org. Thanks, - The Subversion Team
Re: svn commit: r1156954 - in /subversion/site/publish: index.html news.html
Hi Hyrum, -pWe are pleased to announce to release of Apache Subversion 1.7.0-beta3. This +pWe are pleased to announce the release of Apache Subversion 1.7.0-beta3. This Gavin On 12/08/2011, at 1:43 PM, hwri...@apache.org wrote: Author: hwright Date: Fri Aug 12 03:43:48 2011 New Revision: 1156954 URL: http://svn.apache.org/viewvc?rev=1156954view=rev Log: Publish 1.7.0-beta3 to the website. * publish/news.html (news-20110812): New. * publish/index.html (news-20110812): New. (news-20110623): Remove. Modified: subversion/site/publish/index.html subversion/site/publish/news.html Modified: subversion/site/publish/index.html URL: http://svn.apache.org/viewvc/subversion/site/publish/index.html?rev=1156954r1=1156953r2=1156954view=diff == --- subversion/site/publish/index.html (original) +++ subversion/site/publish/index.html Fri Aug 12 03:43:48 2011 @@ -64,6 +64,28 @@ !-- In general, we'll keep only the most recent 3 or 4 news items here. -- +div class=h3 id=news-20110812 +h32011-08-12 mdash; Apache Subversion 1.7.0-beta3 Released + a class=sectionlink href=#news-20110812 + title=Link to this sectionpara;/a +/h3 + +pWe are pleased to announce to release of Apache Subversion 1.7.0-beta3. This + release is not intended for production use, but is provided as a milestone + to encourage wider testing and feedback from intrepid users and maintainers. + Please see the + a href=http://svn.haxx.se/dev/archive-2011-08/0219.shtml;release + announcement/a for more information about this release, and the + a href=/docs/release-notes/1.7.htmlrelease notes/a and + a href=http://svn.apache.org/repos/asf/subversion/tags/1.7.0-beta3/CHANGES; + change log/a for information about what will eventually be + in the 1.7.0 release./p + +pTo get this release from the nearest mirror, please visit our + a href=/download/#pre-releasesdownload page/a./p + +/div !-- #news-20110812 -- + div class=h3 id=news-20110724 h32011-07-24 mdash; Apache Subversion 1.7.0-beta2 Released a class=sectionlink href=#news-20110724 @@ -112,29 +134,6 @@ /div !-- #news-20110711 -- -div class=h3 id=news-20110623 -h32011-06-23 mdash; Apache Subversion 1.7.0-alpha2 Released - a class=sectionlink href=#news-20110623 - title=Link to this sectionpara;/a -/h3 - -pWe are please to announce the next Subversion 1.7.0 prerelease: - Apache Subversion 1.7.0-alpha2. This - release is not intended for production use, but is provided as a milestone - to encourage wider testing and feedback from intrepid users and maintainers. - Please see the - a href=http://svn.haxx.se/dev/archive-2011-06/0764.shtml;release - announcement/a for more information about this release, and the - a href=/docs/release-notes/1.7.htmlrelease notes/a and - a href=http://svn.apache.org/repos/asf/subversion/tags/1.7.0-alpha2/CHANGES; - change log/a for information about what will eventually be - in the 1.7.0 release./p - -pTo get this release from the nearest mirror, please visit our - a href=/download/#pre-releasesdownload page/a./p - -/div !-- #news-20110623 -- - p style=font-style: italic; text-align: right;[Click a href=/news.htmlhere/a to see all News Modified: subversion/site/publish/news.html URL: http://svn.apache.org/viewvc/subversion/site/publish/news.html?rev=1156954r1=1156953r2=1156954view=diff == --- subversion/site/publish/news.html (original) +++ subversion/site/publish/news.html Fri Aug 12 03:43:48 2011 @@ -22,6 +22,28 @@ !-- Maybe we could insert H2's to split up the news items by -- !-- calendar year if we felt the need to do so. -- +div class=h3 id=news-20110812 +h32011-08-12 mdash; Apache Subversion 1.7.0-beta3 Released + a class=sectionlink href=#news-20110812 + title=Link to this sectionpara;/a +/h3 + +pWe are pleased to announce to release of Apache Subversion 1.7.0-beta3. This + release is not intended for production use, but is provided as a milestone + to encourage wider testing and feedback from intrepid users and maintainers. + Please see the + a href=http://svn.haxx.se/dev/archive-2011-08/0219.shtml;release + announcement/a for more information about this release, and the + a href=/docs/release-notes/1.7.htmlrelease notes/a and + a href=http://svn.apache.org/repos/asf/subversion/tags/1.7.0-beta3/CHANGES; + change log/a for information about what will eventually be + in the 1.7.0 release./p + +pTo get this release from the nearest mirror, please visit our + a href=/download/#pre-releasesdownload page/a./p + +/div !-- #news-20110812 -- + div class=h3 id=news-20110724 h32011-07-24 mdash; Apache Subversion 1.7.0-beta2 Released a class=sectionlink href=#news-20110724
Re: [VOTE]: Default http-client for 1.7 Serf or Neon
On Fri, Aug 5, 2011 at 2:34 AM, Greg Stein gst...@gmail.com wrote: Yet... we have seen bugs crop up over the past week in a number of other areas (merge? mod_dav_svn? log? fs txns?). We accept those as normal. They're fixed and backported. This is how we should be operating on ra_serf, too. There is nothing special about it. +1. I feel that there are certain folks in the community that are constantly and actively changing the goal posts. Every time someone says, Oh, ra_serf can't do X or ra_serf isn't as fast as ra_neon, we either add those features or significantly beat the pants off ra_neon. We've been passing all of the functionality tests for years now - yet nothing we do is ever good enough for some. I'm still not aware of any issues that we haven't either fixed or have come up with solutions for. -- justin
