Re: svn commit: r1339892 -

On Fri, May 18, 2012 at 1:57 AM, Greg Stein wrote: > On Fri, May 18, 2012 at 1:34 AM, Bert Huijben wrote: >> >> Editor v1 only requires the revision for base node replacements and I >> don't see why we need to change that for v2. >> >> If we copied a subtree from a revision we know that that revi

Re: svn commit: r1339892 -

On Fri, May 18, 2012 at 1:34 AM, Bert Huijben wrote: > > Editor v1 only requires the revision for base node replacements and I > don't see why we need to change that for v2. > > If we copied a subtree from a revision we know that that revision > didn't change. How could it be out of date? The FS

RE: svn commit: r1339892 -

/subversion/trunk/subversion/libsvn_fs/editor.c MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d04428c9c9dfedd04c046d8da --f46d04428c9c9dfedd04c046d8da Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Editor v1 only requires the revision for base node

Re: svn commit: r1339892 - /subversion/trunk/subversion/libsvn_fs/editor.c

On May 17, 2012 10:38 PM, "Hyrum K Wright" wrote: > > Thanks for taking a look. It feels like all of these are issues with > the complex copies and inheriting the correct replacement revision. > The problem then lies back in the commit driver, but I don't think it > will be too hard to track down

Re: svn commit: r1339892 - /subversion/trunk/subversion/libsvn_fs/editor.c

Thanks for taking a look. It feels like all of these are issues with the complex copies and inheriting the correct replacement revision. The problem then lies back in the commit driver, but I don't think it will be too hard to track down. The blame test failure is an unrelated EOL repairing issue

Re: svn commit: r1339892 - /subversion/trunk/subversion/libsvn_fs/editor.c

Notes: copy 29: a mixed-rev child of a copied parent that is re-copied to pick up a different source revision needs to specify that parent revision for REPLACES_REV. Since it passes SVN_INVALID_REVNUM, the existence check comes into play, and the node exists (implicitly as a result of copying the

Re: svn commit: r1339892 - /subversion/trunk/subversion/libsvn_fs/editor.c

Hyrum, This fixes the two tree_conflict tests you mentioned, and blame 7 continues to fail. However, it introduced failures in copy 29, merge 18, and switch 33. Each one has the error that I just added. I haven't investigated yet: it could be that a different error was expected. (all this on the

Re: svn commit: r1339875 - /subversion/branches/fix-rdump-editor/

On Thu, May 17, 2012 at 4:49 PM, wrote: > Author: hwright > Date: Thu May 17 21:49:01 2012 > New Revision: 1339875 > > URL: http://svn.apache.org/viewvc?rev=1339875&view=rev > Log: > Remove a branch whose useful life has ended. > > Removed: >    subversion/branches/fix-rdump-editor/ For those th

Re: [DISCUSS] delete ra_neon

On Thu, May 17, 2012 at 4:47 PM, Ivan Zhakov wrote: >... > I meant one PROPFIND per directory. I didn't see where PROPFIND with > "1" depth is created. It used only in svn_ra_serf__get_dir() but not > in update driver code. Today, we do a PROPFIND per node. I want to change it to per-directory. I

Re: [DISCUSS] delete ra_neon

On Fri, May 18, 2012 at 12:35 AM, C. Michael Pilato wrote: > On 05/17/2012 04:26 PM, Ivan Zhakov wrote: >> On Thu, May 17, 2012 at 8:02 PM, C. Michael Pilato >> wrote: >>> On 05/17/2012 11:45 AM, Greg Stein wrote: On May 17, 2012 10:27 AM, "C. Michael Pilato" >>>

Re: [DISCUSS] delete ra_neon

On 05/17/2012 04:26 PM, Ivan Zhakov wrote: > On Thu, May 17, 2012 at 8:02 PM, C. Michael Pilato > wrote: >> On 05/17/2012 11:45 AM, Greg Stein wrote: >>> >>> On May 17, 2012 10:27 AM, "C. Michael Pilato" >> > wrote: ... No, I haven't yet taken a crack at remo

Re: [DISCUSS] delete ra_neon

On 05/17/2012 04:19 PM, Ivan Zhakov wrote: > On Wed, May 16, 2012 at 2:46 PM, Greg Stein wrote: >> Short query: is this possible? >> >> Long query: >> >> Hyrum has been doing some heavy lifting on moving our code to Ev2 for >> commits. That work can be merged soonish, but a strong argument can be

Re: [DISCUSS] delete ra_neon

On Thu, May 17, 2012 at 8:02 PM, C. Michael Pilato wrote: > On 05/17/2012 11:45 AM, Greg Stein wrote: >> >> On May 17, 2012 10:27 AM, "C. Michael Pilato" > > wrote: >>>... >>> No, I haven't yet taken a crack at removing the HEAD request.  That will >>> significantly hel

Re: [DISCUSS] delete ra_neon

On Wed, May 16, 2012 at 2:46 PM, Greg Stein wrote: > Short query: is this possible? > > Long query: > > Hyrum has been doing some heavy lifting on moving our code to Ev2 for > commits. That work can be merged soonish, but a strong argument can be made > for "only when all RA providers have an Ev2

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

Hyrum K Wright wrote on Thu, May 17, 2012 at 12:59:23 -0500: > I'lll also point out that in the past downstream users have made the > determination for us, and requested their own CVEs for issues in our > releases. I don't think that's a problem, and we can't really control > how downstream judges

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

Greg Stein wrote on Thu, May 17, 2012 at 13:50:55 -0400: > Dunno. Probably for that one, yeah. I just took a quick look at 1.7.1 and > 1.7.2 and nothing jumped out. so +1 on s/security// for them > On May 17, 2012 1:31 PM, "Philip Martin" > wrote: > > > 1.7.5 includes r1298343 a server SEGV t

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

On Thu, May 17, 2012 at 12:51 PM, Julian Foad wrote: > Philip Martin wrote: >> 1.7.5 includes r1298343 a server SEGV that can only be triggered by >> those with commit access.  We never bothered getting a CVE for >> that.  Does that mean we can't call it a security release? > > What's the point in

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

Philip Martin wrote: > 1.7.5 includes r1298343 a server SEGV that can only be triggered by > those with commit access.  We never bothered getting a CVE for > that.  Does that mean we can't call it a security release? What's the point in having two different definitions of the term "security"?  I

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

Dunno. Probably for that one, yeah. I just took a quick look at 1.7.1 and 1.7.2 and nothing jumped out. On May 17, 2012 1:31 PM, "Philip Martin" wrote: > 1.7.5 includes r1298343 a server SEGV that can only be triggered by > those with commit access. We never bothered getting a CVE for > that.

Re: bug in can_modify()

On May 17, 2012 1:04 PM, "Hyrum K Wright" wrote: > > On Thu, May 17, 2012 at 11:00 AM, Greg Stein wrote: >... > > I got my Ev2 branch going last night, and got about 20 failures. Does that > > sound right? > > Over ra_local, I only see the following 3 failures: > FAIL: blame_tests.py 7: blame wi

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

1.7.5 includes r1298343 a server SEGV that can only be triggered by those with commit access. We never bothered getting a CVE for that. Does that mean we can't call it a security release? Greg Stein writes: > Should we the term "security" if a release does not have a CVE associated > with it?

Re: bug in can_modify()

On Thu, May 17, 2012 at 11:00 AM, Greg Stein wrote: > > On May 17, 2012 11:53 AM, "Hyrum K Wright" > wrote: >> >> On Wed, May 16, 2012 at 11:27 PM, Greg Stein wrote: >>... > >> > Right. The add/copy should fail because the node already exists. I >> > relied on >> > that failure, rather than issu

Re: svn commit: r1339559 - /subversion/site/publish/docs/release-notes/release-history.html

Should we the term "security" if a release does not have a CVE associated with it? On May 17, 2012 7:45 AM, wrote: > Author: philip > Date: Thu May 17 11:44:39 2012 > New Revision: 1339559 > > URL: http://svn.apache.org/viewvc?rev=1339559&view=rev > Log: > * publish/release-notes/release-history.

Re: [DISCUSS] delete ra_neon

On 05/17/2012 11:45 AM, Greg Stein wrote: > > On May 17, 2012 10:27 AM, "C. Michael Pilato" > wrote: >>... >> No, I haven't yet taken a crack at removing the HEAD request. That will >> significantly help the fetch-from-pristine-cache situation, but this is a >> parall

Re: bug in can_modify()

On May 17, 2012 11:53 AM, "Hyrum K Wright" wrote: > > On Wed, May 16, 2012 at 11:27 PM, Greg Stein wrote: >... > > Right. The add/copy should fail because the node already exists. I relied on > > that failure, rather than issuing an OOD. We could add that empty-target > > verification. > > I thin

Re: bug in can_modify()

On Wed, May 16, 2012 at 11:27 PM, Greg Stein wrote: > > On May 15, 2012 6:04 PM, "Hyrum K Wright" wrote: >>... > > >> This research comes as a result of the final test failures on the >> ev2-export branch for commit: tree conflicts tests 4 and 8.  Both of >> these set up the tree conflict scenari

Announcing the release of EasySVN

Assembla is announcing the release of EasySVN, a free, open-source Subversion client with unique features to make Subversion easier to use. We just posted a 1.0 release for Windows and a beta release for Macintosh. You can download them from http://assemb.la/EasySVN EasySVN adds the following capa

Re: [DISCUSS] delete ra_neon

On May 17, 2012 10:27 AM, "C. Michael Pilato" wrote: >... > No, I haven't yet taken a crack at removing the HEAD request. That will > significantly help the fetch-from-pristine-cache situation, but this is a > parallel line of optimization that needs to occur. Yup. Doable; not worried about it.

Re: [DISCUSS] delete ra_neon

On 05/17/2012 09:48 AM, Mark Phippard wrote: > On Thu, May 17, 2012 at 9:45 AM, C. Michael Pilato > wrote: >> On 05/17/2012 03:43 AM, Justin Erenkrantz wrote: >>> Again, the outstanding optimization to do on the ra_serf side is to >>> reduce the number of PROPFIND requests and make that not propo

Re: [DISCUSS] delete ra_neon

On 05/17/2012 09:45 AM, C. Michael Pilato wrote: > On 05/17/2012 03:43 AM, Justin Erenkrantz wrote: >> Again, the outstanding optimization to do on the ra_serf side is to >> reduce the number of PROPFIND requests and make that not proportional >> to the number of files - most likely either to the n

Re: [DISCUSS] delete ra_neon

On Thu, May 17, 2012 at 9:45 AM, C. Michael Pilato wrote: > On 05/17/2012 03:43 AM, Justin Erenkrantz wrote: >> Again, the outstanding optimization to do on the ra_serf side is to >> reduce the number of PROPFIND requests and make that not proportional >> to the number of files - most likely eithe

Re: [DISCUSS] delete ra_neon

On 05/17/2012 03:43 AM, Justin Erenkrantz wrote: > Again, the outstanding optimization to do on the ra_serf side is to > reduce the number of PROPFIND requests and make that not proportional > to the number of files - most likely either to the number of > directories or only when custom properties

Subversion 1.7.5 released

I'm happy to announce the release of Apache Subversion 1.7.5. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release The SHA1 checksums are: 05c079762690d5ac1ccd2549742e7ef70fa45cf1 subversion-1.7.5.tar.bz2 52fcc730232623497491

Re: new conflict callback API

Stefan Sperling wrote: > On Wed, May 16, 2012 at 02:52:06PM +0100, Julian Foad wrote: >> OK, I appreciate that issue.  I see two ways the client lib can help: >> >> 1. providing a set of client-lib APIs to perform the most commonly >> wanted resolutions; >> >> 2. providing a set of (APIs? com

Re: [DISCUSS] delete ra_neon

On Wed, May 16, 2012 at 12:12 PM, Philip Martin wrote: > I do. Look at the numbers in the issue.  I compare neon and serf with > mod-deflate. I compare neon and serf without mod-deflate.  I compare > neon and serf over https. I maintain that's still not a fair comparison - but, let me elaborate o

Re: [DISCUSS] delete ra_neon

On Wed, May 16, 2012 at 10:40 AM, C. Michael Pilato wrote: > On 05/16/2012 10:13 AM, Greg Stein wrote: >> On Wed, May 16, 2012 at 9:43 AM, C. Michael Pilato >> wrote: >>> but:  How hard would it be to temporarily maintain two commit paths -- one >>> that drives an Ev2 editor, and one that drives

AW: new conflict callback API

Hi, Stefan, Von: Stefan Sperling [s...@elego.de] On Wed, May 16, 2012 at 02:52:46PM +, Markus Schaber wrote: >> Hmm, this may lead to _very_ special strategies implemented in the core. >> >> Like when a CoDeSys Device plugged into a Slot conflicts, and a neighbor >> slot is empty. >> >> On t