Re: another serf crash

On Jun 24, 2011 5:02 PM, "Stefan Sperling" wrote: > > On Fri, Jun 24, 2011 at 01:55:13PM -0400, Greg Stein wrote: > > Yeah, that was fixed a week or two ago on trunk (I assume you're using > > 0.7.2?) > > I'm using 0.7.x from a few days ago. > > I'll try to update to serf trunk. I suppose serf tru

Re: another serf crash

[Stefan Sperling] > I'll try to update to serf trunk. I suppose serf trunk will become > serf 1.0 and we should all be testing with trunk at this point > rather than 0.7.x? Note if you do update to serf trunk, you'll need to patch build/ac-macros/serf.m4: http://svn.haxx.se/dev/archive-2011-

Re: another serf crash

On Fri, Jun 24, 2011 at 01:55:13PM -0400, Greg Stein wrote: > Yeah, that was fixed a week or two ago on trunk (I assume you're using > 0.7.2?) I'm using 0.7.x from a few days ago. I'll try to update to serf trunk. I suppose serf trunk will become serf 1.0 and we should all be testing with trunk a

Re: svn commit: r1131389 - /subversion/trunk/subversion/libsvn_subr/magic.c

On Fri, Jun 24, 2011 at 09:49:31PM +0300, Daniel Shahaf wrote: > > +#ifndef MAGIC_MIME_TYPE > > + char *p; > > + > > + /* Strip off trailing stuff like " charset=ascii". */ > > + p = strchr(magic_mimetype, ' '); > > + if (p) > > + *p = '\

Re: serf infinite loop in svn_ra_serf__handle_xml_parser()

On Fri, Jun 24, 2011 at 01:46:42PM -0400, Greg Stein wrote: > When you say "success", you mean status==0? Yup. > No, it would never block. The bucket should return EAGAIN when it has no > more data. I see. Lieven explained this too and also pointed to a related (or the same) issue documented el

Re: another serf crash

On Fri, Jun 24, 2011 at 11:08 AM, Greg Stein wrote: >> You can disable wire compression in your server config file. > > On the client side. http-compression = no HTH. -- justin

Re: 'svn log --diff' foils log output parsers

On 06/24/2011 01:35 PM, Branko Čibej wrote: > On 24.06.2011 17:50, C. Michael Pilato wrote: >> Having read and considered the replies received thus far, I'm dubbing this a >> non-issue and moving on. Thanks for the feedback, all who provided it. > > Just for the record, this same issue has existe

Re: README in our dist mirrors

The file is chmod'd g+w, feel free to patch it. Hyrum K Wright wrote on Fri, Jun 24, 2011 at 14:16:18 -0500: > True, but if somebody lands in > http://archive.apache.org/dist/subversion/, they will see all the > tarballs, and might naturally look for a README. Having found it, > they would read t

Re: README in our dist mirrors

True, but if somebody lands in http://archive.apache.org/dist/subversion/, they will see all the tarballs, and might naturally look for a README. Having found it, they would read the following text and be completely befuddled ("are you telling me I can't download a release from here? It's the arc

Re: README in our dist mirrors

/download/ and /packages are the canonical location for "Where do I download 1.6.x from?", so they ought to link to the archive. Hyrum K Wright wrote on Fri, Jun 24, 2011 at 14:05:59 -0500: > Good idea. However, this file will be mirrored to the archive, and > read there isn't technically correct

Re: README in our dist mirrors

Good idea. However, this file will be mirrored to the archive, and read there isn't technically correct, since the 1.6.x releases are hosted on archive.apache.org. -Hyrum On Fri, Jun 24, 2011 at 11:11 AM, Daniel Shahaf wrote: > I've added the following README to our dist/ directory on > people.

Re: svn commit: r1131389 - /subversion/trunk/subversion/libsvn_subr/magic.c

s...@apache.org wrote on Sat, Jun 04, 2011 at 13:04:51 -: > Author: stsp > Date: Sat Jun 4 13:04:51 2011 > New Revision: 1131389 > > URL: http://svn.apache.org/viewvc?rev=1131389&view=rev > Log: > Work around older libmagic versions that don't define MAGIC_MIME_TYPE. > > This should fix the

Re: [PATCH] svn 1.7 should ship with serf 1.0.x

[Greg Stein] > For now, we should detect both. We can rip out the older support after a > bit. IOW, please apply. > > The patch has serf/build/get-version.sh, but that is not in the serf > release? Looks like it's borrowed from apr, copied into the serf source tree by 'buildconf'. In any case,

Re: another serf crash

On Jun 24, 2011 2:07 PM, "Greg Stein" wrote: > > > On Jun 24, 2011 1:57 PM, "Daniel Shahaf" wrote: > > > > Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100: > > > Daniel Shahaf writes: > > > > > > > ==15085== Conditional jump or move depends on uninitialised value(s) > > > > ==15085==

Re: another serf crash

On Jun 24, 2011 1:57 PM, "Daniel Shahaf" wrote: > > Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100: > > Daniel Shahaf writes: > > > > > ==15085== Conditional jump or move depends on uninitialised value(s) > > > ==15085==at 0x4629A2E: inflateReset2 (in /usr/lib/libz.so.1.2.3.4) > >

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

To be clear: all attachments, regardless of extension or declared MIME type will get through? On Jun 24, 2011 12:28 PM, "Daniel Shahaf" wrote: > Update: MIME attachment removal has been disabled for this list. > > > Thanks everyone for collecting extensions, and Gavin and Joe for > addressing the

Re: another serf crash

Daniel Shahaf writes: > Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100: >> zlib doesn't play well with valgrind, see for example: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287603 >> >> so this may be a false positive. > > Can I disable all forms of compression that migh

Re: another serf crash

Philip Martin wrote on Fri, Jun 24, 2011 at 18:50:59 +0100: > Daniel Shahaf writes: > > > ==15085== Conditional jump or move depends on uninitialised value(s) > > ==15085==at 0x4629A2E: inflateReset2 (in /usr/lib/libz.so.1.2.3.4) > > ==15085==by 0x4629B0C: inflateInit2_ (in /usr/lib/libz.

Re: another serf crash

Yeah, that was fixed a week or two ago on trunk (I assume you're using 0.7.2?) On Jun 24, 2011 1:28 PM, "Stefan Sperling" wrote: > I don't know if this is already known, so I am reporting it > here to get confirmation. > > (From #svn-dev): > run svn log --diff -r1139384 for fun > with serf > Ct

Re: serf infinite loop in svn_ra_serf__handle_xml_parser()

On Fri, Jun 24, 2011 at 2:44 PM, Stefan Sperling wrote: > Trying to update my working copy I observed svn spinning on the CPU > forever. Attaching with gdb showed that it was stuck in an endless > loop inside svn_ra_serf__handle_xml_parser(). > > Below is the code. The problem was that serf_bucket

Re: another serf crash

Daniel Shahaf writes: > ==15085== Conditional jump or move depends on uninitialised value(s) > ==15085==at 0x4629A2E: inflateReset2 (in /usr/lib/libz.so.1.2.3.4) > ==15085==by 0x4629B0C: inflateInit2_ (in /usr/lib/libz.so.1.2.3.4) > ==15085==by 0x428E453: serf_deflate_read (deflate_bu

Re: serf infinite loop in svn_ra_serf__handle_xml_parser()

On Jun 24, 2011 8:45 AM, "Stefan Sperling" wrote: > > Trying to update my working copy I observed svn spinning on the CPU > forever. Attaching with gdb showed that it was stuck in an endless > loop inside svn_ra_serf__handle_xml_parser(). > > Below is the code. The problem was that serf_bucket_rea

Re: 'svn log --diff' foils log output parsers

Branko Čibej wrote on Fri, Jun 24, 2011 at 19:35:14 +0200: > On 24.06.2011 17:50, C. Michael Pilato wrote: > > Having read and considered the replies received thus far, I'm dubbing this a > > non-issue and moving on. Thanks for the feedback, all who provided it. > > Just for the record, this same

Re: another serf crash

Stefan Sperling wrote on Fri, Jun 24, 2011 at 19:27:44 +0200: > I don't know if this is already known, so I am reporting it > here to get confirmation. > > (From #svn-dev): > run svn log --diff -r1139384 for fun > with serf > Ctrl-C out in the middle when it prints diff text > -> core dump >

Re: [PATCH] svn 1.7 should ship with serf 1.0.x

For now, we should detect both. We can rip out the older support after a bit. IOW, please apply. The patch has serf/build/get-version.sh, but that is not in the serf release? Cheers, -g On Jun 24, 2011 12:35 PM, "Peter Samuelson" wrote:

Re: 'svn log --diff' foils log output parsers

On 24.06.2011 17:50, C. Michael Pilato wrote: > Having read and considered the replies received thus far, I'm dubbing this a > non-issue and moving on. Thanks for the feedback, all who provided it. Just for the record, this same issue has existed since "svn log" first accepted the --verbose flag.

Re: another serf crash

On Fri, Jun 24, 2011 at 07:27:44PM +0200, Stefan Sperling wrote: > I don't know if this is already known, so I am reporting it > here to get confirmation. > > (From #svn-dev): > run svn log --diff -r1139384 for fun > with serf > Ctrl-C out in the middle when it prints diff text > -> core dump

another serf crash

I don't know if this is already known, so I am reporting it here to get confirmation. (From #svn-dev): run svn log --diff -r1139384 for fun with serf Ctrl-C out in the middle when it prints diff text -> core dump #0 0x000204cef469 in destroy_request (request=0x2083f47b8) at ./outgoi

[PATCH] svn 1.7 should ship with serf 1.0.x

[Greg Stein] > Just a heads up: the serf devs plan to bump serf from 0.7.x to 1.0.x > on the next release (imminent). Speaking o' which, I think we need something like the following in Subversion. It is untested. Of course, if we really want to drop support for serf pre 1.0, the patch gets a lo

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

On Fri, Jun 24, 2011 at 07:27:55PM +0300, Daniel Shahaf wrote: > Update: MIME attachment removal has been disabled for this list. > > > Thanks everyone for collecting extensions, and Gavin and Joe for > addressing the issue. Thank you all!

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

Update: MIME attachment removal has been disabled for this list. Thanks everyone for collecting extensions, and Gavin and Joe for addressing the issue.

README in our dist mirrors

I've added the following README to our dist/ directory on people.apache.org: [[[ For stable releases visit or . ]]] This is since currently only 1.7.0-alpha2 (but no 1.6.x or 1.5.x) is on the Apache mirrors.

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

Ivan Zhakov wrote on 06/24/2011 10:46:37 AM: > On Fri, Jun 24, 2011 at 17:48, wrote: > > > > Is anybody using serf with negotiate authentication? I can't get it to > > work with a 1.6.5 server using mod_auth_kerb and negotiate. > > > > The server sends the 401: > > > > WWW-Authenticate: Negoti

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Fri, Jun 24, 2011 at 07:50:15PM +0400, Ivan Zhakov wrote: > I've tested > Negotiate (Kerberos) authentication in TortoiseSVN using serf in our > environment and it works in simple cases. So... what happens in complex cases? :) Are there cases which neon can handle that serf cannot?

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Fri, Jun 24, 2011 at 11:50 AM, Ivan Zhakov wrote: > serf uses SSPI for Kerberos on Windows and it should be automatically > enabled if your build serf 0.7 or later on Windows. I've tested > Negotiate (Kerberos) authentication in TortoiseSVN using serf in our > environment and it works in simpl

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Fri, Jun 24, 2011 at 17:50, Mark Phippard wrote: > On Fri, Jun 24, 2011 at 9:48 AM,   wrote: > >> Is anybody using serf with negotiate authentication?  I can't get it to >> work with a 1.6.5 server using mod_auth_kerb and negotiate. >> >> The server sends the 401: >> >> WWW-Authenticate: Negoti

Re: 'svn log --diff' foils log output parsers

Having read and considered the replies received thus far, I'm dubbing this a non-issue and moving on. Thanks for the feedback, all who provided it. On 06/23/2011 03:15 PM, C. Michael Pilato wrote: > When we designed 'svn log' many moons ago, we added the "N lines" header > information to aid par

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Fri, Jun 24, 2011 at 17:48, wrote: > > Is anybody using serf with negotiate authentication?  I can't get it to > work with a 1.6.5 server using mod_auth_kerb and negotiate. > > The server sends the 401: > > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="my realm" > > correctly, b

RE: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

> -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: vrijdag 24 juni 2011 15:24 > To: dev@subversion.apache.org > Subject: Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] > (INFRA-3724) attachments sent get dropped without notification to either > s

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

.xz .txz -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.

Re: should we really ship serf as default for 1.7?

Stefan Küng wrote on 06/24/2011 09:04:41 AM: > On 24.06.2011 15:50, Mark Phippard wrote: > > On Fri, Jun 24, 2011 at 9:48 AM, wrote: > > > >> Is anybody using serf with negotiate authentication? I can't get it to > >> work with a 1.6.5 server using mod_auth_kerb and negotiate. > >> > >> The ser

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

Stefan Sperling wrote on 06/24/2011 09:02:15 AM: > On Fri, Jun 24, 2011 at 08:55:02AM -0500, kmra...@rockwellcollins.com wrote: > > Not sure, but I know serf shouldn't keep sending the same endless > > unauthenticated request until I control-C the command. No indication > > it was even doing any

Re: should we really ship serf as default for 1.7?

On 24.06.2011 15:50, Mark Phippard wrote: On Fri, Jun 24, 2011 at 9:48 AM, wrote: Is anybody using serf with negotiate authentication? I can't get it to work with a 1.6.5 server using mod_auth_kerb and negotiate. The server sends the 401: WWW-Authenticate: Negotiate WWW-Authenticate: Basic

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Fri, Jun 24, 2011 at 08:55:02AM -0500, kmra...@rockwellcollins.com wrote: > Not sure, but I know serf shouldn't keep sending the same endless > unauthenticated request until I control-C the command. No indication > it was even doing anything until I put a proxy in between to sniff > the traffic

Re: "Apache's APR version doesn't match configure's"

On Fri, Jun 24, 2011 at 4:45 AM, Philip Martin wrote: > Hyrum K Wright writes: > >> moving forward, not backward.  One possible solution is to just not >> build mod_dav_svn, rather than torpedoing the entire build, if >> Apache's APR doesn't match configure's.  In any case, I think the >> current

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

Mark Phippard wrote on 06/24/2011 08:50:22 AM: > On Fri, Jun 24, 2011 at 9:48 AM, wrote: > > > Is anybody using serf with negotiate authentication? I can't get it to > > work with a 1.6.5 server using mod_auth_kerb and negotiate. > > > > The server sends the 401: > > > > WWW-Authenticate: Neg

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Fri, Jun 24, 2011 at 9:48 AM, wrote: > Is anybody using serf with negotiate authentication?  I can't get it to > work with a 1.6.5 server using mod_auth_kerb and negotiate. > > The server sends the 401: > > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="my realm" > > correctly,

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

Stefan Sperling wrote on 06/24/2011 08:06:28 AM: > Subject: should we really ship serf as default for 1.7? (was: Re: > serf and sourceforge.net don't get along) > > On Wed, Jun 22, 2011 at 09:17:37PM -0400, C. Michael Pilato wrote: > > On 06/22/2011 07:30 PM, Daniel Shahaf wrote: > > > Bolstridg

Re: [PATCH] possible improvement to svn log with "forward" revision range (issue 3830)

On 06/23/2011 07:18 PM, Dirk Thomas wrote: > Well, since issue 3931 was fixed today > ('svn log' is returning log of unrelated path when peg revision is not > related to operative revision) > i revisited my patch for issue 3830. > > > + /* try fetching ra_session again > + * this time with modif

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

.tgz .tbz

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

.zip .tar .gz .bz2 .7z

RE: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

> -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: vrijdag 24 juni 2011 15:16 > To: Johan Corveleyn > Cc: Hyrum K Wright; Ivan Zhakov; dev@subversion.apache.org > Subject: Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] > (INFRA-3724) attachment

Re: serf infinite loop in svn_ra_serf__handle_xml_parser()

On Fri, Jun 24, 2011 at 02:44:45PM +0200, Stefan Sperling wrote: > Trying to update my working copy I observed svn spinning on the CPU > forever. Attaching with gdb showed that it was stuck in an endless > loop inside svn_ra_serf__handle_xml_parser(). Forgot to mention that I have on reliable way

Re: should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Fri, Jun 24, 2011 at 9:06 AM, Stefan Sperling wrote: > I am still uneasy about this. Same here. > Given the number of issues that have been filed against ra_serf recently, > and issues that I've personally been running into when using it (all > reported to dev@), I am still not convinced tha

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

Johan Corveleyn wrote on Fri, Jun 24, 2011 at 15:10:16 +0200: > On Fri, Jun 24, 2011 at 2:58 PM, Hyrum K Wright wrote: > > On Fri, Jun 24, 2011 at 6:49 AM, Ivan Zhakov wrote: > >> On Fri, Jun 24, 2011 at 14:46, Daniel Shahaf wrote: > >>> Daniel Shahaf wrote on Fri, Jun 24, 2011 at 13:44:03 +0300

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

On Fri, Jun 24, 2011 at 2:58 PM, Hyrum K Wright wrote: > On Fri, Jun 24, 2011 at 6:49 AM, Ivan Zhakov wrote: >> On Fri, Jun 24, 2011 at 14:46, Daniel Shahaf wrote: >>> Daniel Shahaf wrote on Fri, Jun 24, 2011 at 13:44:03 +0300: Rejecting to the OP doesn't seem to be an option.  (Rejecting t

should we really ship serf as default for 1.7? (was: Re: serf and sourceforge.net don't get along)

On Wed, Jun 22, 2011 at 09:17:37PM -0400, C. Michael Pilato wrote: > On 06/22/2011 07:30 PM, Daniel Shahaf wrote: > > Bolstridge, Andrew wrote on Wed, Jun 22, 2011 at 14:51:37 +: > >> Absolutely. The first thing to do is provide serf as a 2nd option, > >> make a big song and dance about how gre

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

On Fri, Jun 24, 2011 at 6:49 AM, Ivan Zhakov wrote: > On Fri, Jun 24, 2011 at 14:46, Daniel Shahaf wrote: >> Daniel Shahaf wrote on Fri, Jun 24, 2011 at 13:44:03 +0300: >>> Rejecting to the OP doesn't seem to be an option.  (Rejecting to >>> a constant address /is/ an option, but it'd be all reje

serf infinite loop in svn_ra_serf__handle_xml_parser()

Trying to update my working copy I observed svn spinning on the CPU forever. Attaching with gdb showed that it was stuck in an endless loop inside svn_ra_serf__handle_xml_parser(). Below is the code. The problem was that serf_bucket_read() returned zero bytes but also indicated success. If that ha

Re: [PATCH] Fix for issue #3938 - revert throws an error for unversioned targets

r1139275, thanks. Noorul Islam K M wrote on Fri, Jun 24, 2011 at 17:05:04 +0530: > > Log > > [[[ > Fix for issue #3938. Make 'svn revert' to skip unversioned targets. > > * subversion/libsvn_client/revert.c > (revert): Send 'skip' notification when svn_wc_revert4() returns > SVN_ERR_WC_P

Re: Implement support for 'make check' variants

Philip Martin wrote on Fri, Jun 24, 2011 at 13:03:27 +0100: > Daniel Shahaf writes: > > > SERVER_MINOR_VERSION is for testing a 1.7 client with a 1.6 server. > > > > I'm after testing a 1.7 client with a 1.7 server using a 1.6 filesystme. > > As discussed on IRC, SERVER_MINOR_VERSION should alre

RE: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Friday, 24 June 2011 9:39 PM > To: Daniel Shahaf > Cc: dev@subversion.apache.org > Subject: Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] > (INFRA-3724) attachments sent get dropped without notifi

Re: Implement support for 'make check' variants

Daniel Shahaf writes: > SERVER_MINOR_VERSION is for testing a 1.7 client with a 1.6 server. > > I'm after testing a 1.7 client with a 1.7 server using a 1.6 filesystme. As discussed on IRC, SERVER_MINOR_VERSION should already cause a 1.6 filesystem to be used. However there is a bug somewhere i

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

On Fri, Jun 24, 2011 at 14:46, Daniel Shahaf wrote: > Daniel Shahaf wrote on Fri, Jun 24, 2011 at 13:44:03 +0300: >> Rejecting to the OP doesn't seem to be an option.  (Rejecting to >> a constant address /is/ an option, but it'd be all rejections, not just >> 'bad attachment' rejections.) >> >> Se

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

On Fri, Jun 24, 2011 at 01:46:50PM +0300, Daniel Shahaf wrote: > Daniel Shahaf wrote on Fri, Jun 24, 2011 at 13:44:03 +0300: > > Rejecting to the OP doesn't seem to be an option. (Rejecting to > > a constant address /is/ an option, but it'd be all rejections, not just > > 'bad attachment' rejectio

[PATCH] Fix for issue #3938 - revert throws an error for unversioned targets

Log [[[ Fix for issue #3938. Make 'svn revert' to skip unversioned targets. * subversion/libsvn_client/revert.c (revert): Send 'skip' notification when svn_wc_revert4() returns SVN_ERR_WC_PATH_NOT_FOUND. Patch by: Noorul Islam K M ]]] Thanks and Regards Noorul Index: subversion/libsvn

RE: svn commit: r1139080 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

[ sigh. virtual keyboard typo. "inspection" ] On Jun 24, 2011 7:24 AM, "Greg Stein" wrote: > > > On Jun 24, 2011 3:23 AM, "Bert Huijben" wrote: > > > > > > > > > -Original Message- > > > From: Greg Stein [mailto:gst...@gmail.com] > > > Sent: vrijdag 24 juni 2011 2:10 > > > To: dev@subver

RE: svn commit: r1139080 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

On Jun 24, 2011 3:23 AM, "Bert Huijben" wrote: > > > > > -Original Message- > > From: Greg Stein [mailto:gst...@gmail.com] > > Sent: vrijdag 24 juni 2011 2:10 > > To: dev@subversion.apache.org > > Subject: Re: svn commit: r1139080 - > > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > >

Re: Implement support for 'make check' variants

For THREADED, no I don't plan to change it, I simply forgot that I had already added it. Philip Martin wrote on Fri, Jun 24, 2011 at 11:47:44 +0100: > Noorul Islam K M writes: > > > Daniel came up with idea of extending Makefile.in to support 'make > > check' variants. > > > > 1. 'make check' wi

Re: Implement support for 'make check' variants

Philip Martin wrote on Fri, Jun 24, 2011 at 11:47:44 +0100: > Noorul Islam K M writes: > > > Daniel came up with idea of extending Makefile.in to support 'make > > check' variants. > > > > 1. 'make check' with svnserve -T > > > 2. 'make check' with svnadmin create --pre-1.x-compatible (where x i

Re: Implement support for 'make check' variants

Noorul Islam K M writes: > Daniel came up with idea of extending Makefile.in to support 'make > check' variants. > > 1. 'make check' with svnserve -T > 2. 'make check' with svnadmin create --pre-1.x-compatible (where x in >(1.4, 1.5, 1.6, 1.7)) > 3. 'make check' with SVNPathAuthz short_circu

Re: Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

Daniel Shahaf wrote on Fri, Jun 24, 2011 at 13:44:03 +0300: > Rejecting to the OP doesn't seem to be an option. (Rejecting to > a constant address /is/ an option, but it'd be all rejections, not just > 'bad attachment' rejections.) > > Seems the option we do have is to ask for some more filename

Dropped attachments Fwd: [Gavin (JIRA): [jira] [Commented] (INFRA-3724) attachments sent get dropped without notification to either sender or receiving list]

Rejecting to the OP doesn't seem to be an option. (Rejecting to a constant address /is/ an option, but it'd be all rejections, not just 'bad attachment' rejections.) Seems the option we do have is to ask for some more filename extensions to be allowed. So, can we compile a list of extensions we

Re: Implement support for 'make check' variants

Noorul Islam K M wrote on Fri, Jun 24, 2011 at 10:11:50 +0530: > > Daniel came up with idea of extending Makefile.in to support 'make > check' variants. > > 1. 'make check' with svnserve -T > 2. 'make check' with svnadmin create --pre-1.x-compatible (where x in >(1.4, 1.5, 1.6, 1.7)) > 3. 'ma

Re: "Apache's APR version doesn't match configure's"

Hyrum K Wright writes: > moving forward, not backward. One possible solution is to just not > build mod_dav_svn, rather than torpedoing the entire build, if > Apache's APR doesn't match configure's. In any case, I think the > current situation is not viable long term. I made it skip the module

Re: [RFC] Rename 'svn_error_return' to 'svn_error_trace'?

Committed in r1139195. - Julian On Thu, 2011-06-23, Hyrum K Wright wrote: > On Thu, Jun 23, 2011 at 1:17 PM, Julian Foad wrote: > > Greg Stein wrote: > >> Thanks for taking the time to do thus. Only recently did I realize that I > >> named the function incorrectly when I came up with it. In PoCo

RE: svn commit: r1139080 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

> -Original Message- > From: Greg Stein [mailto:gst...@gmail.com] > Sent: vrijdag 24 juni 2011 2:10 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1139080 - > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > On Thu, Jun 23, 2011 at 17:20, wrote: > >... > > +++ subversion