Re: svn commit: r1488464 - /subversion/branches/1.8.x/STATUS
On Sat, Jun 1, 2013 at 1:28 AM, danie...@apache.org wrote: Author: danielsh Date: Sat Jun 1 05:28:20 2013 New Revision: 1488464 URL: http://svn.apache.org/r1488464 Log: * STATUS: Block the r1488183 entry until Paul confirms what the revisions are. Modified: subversion/branches/1.8.x/STATUS Modified: subversion/branches/1.8.x/STATUS URL: http://svn.apache.org/viewvc/subversion/branches/1.8.x/STATUS?rev=1488464r1=1488463r2=1488464view=diff == --- subversion/branches/1.8.x/STATUS (original) +++ subversion/branches/1.8.x/STATUS Sat Jun 1 05:28:20 2013 @@ -64,6 +64,7 @@ Candidate changes: Justification: Prevents a segfault in the new 'internal text conflict merge tool'. Votes: + -1: danielsh (Paul: I think you meant r1488267) Hi Daniel - Quite right, I did mean r1488267. I fixed that in STATUS. +1: pburba (for 1.8.0: This isn't a 'destabilizing' change per my reading of our release-stabilization guidelines, so it can be included in 1.8.0 without a soak restart.) -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
RE: svn commit: r1488538 - /subversion/branches/invoke-diff-cmd-feature/subversion/libsvn_subr/io.c
-Original Message-
From: g...@apache.org [mailto:g...@apache.org]
Sent: zaterdag 1 juni 2013 17:36
To: comm...@subversion.apache.org
Subject: svn commit: r1488538 - /subversion/branches/invoke-diff-cmd-
feature/subversion/libsvn_subr/io.c
Author: gbg
Date: Sat Jun 1 15:36:07 2013
New Revision: 1488538
URL: http://svn.apache.org/r1488538
Log:
On the invoke-diff-cmd branch: Cast NULL to char*.
* subversion/libsvn_subr/io.c
(svn_io_run_external_diff): Cast Null to char*.
Modified:
subversion/branches/invoke-diff-cmd-
feature/subversion/libsvn_subr/io.c
Modified: subversion/branches/invoke-diff-cmd-
feature/subversion/libsvn_subr/io.c
URL: http://svn.apache.org/viewvc/subversion/branches/invoke-diff-cmd-
feature/subversion/libsvn_subr/io.c?rev=1488538r1=1488537r2=1488538
view=diff
==
--- subversion/branches/invoke-diff-cmd-
feature/subversion/libsvn_subr/io.c (original)
+++ subversion/branches/invoke-diff-cmd-
feature/subversion/libsvn_subr/io.c Sat Jun 1 15:36:07 2013
@@ -3035,8 +3035,8 @@ svn_io_run_external_diff(const char *dir
for (i = 0; cmd[i]; ++i)
{
- failed_command = apr_pstrcat(pool, failed_command, cmd[i], NULL);
- failed_command = apr_pstrcat(pool, failed_command, , NULL);
+ failed_command = apr_pstrcat(pool, failed_command, cmd[i], (char*)
NULL);
+ failed_command = apr_pstrcat(pool, failed_command, , (char*)
NULL);
The apr_pstrcat() function allows a variable number of arguments so you can add
cmd[i] and the at the same time. Using separate function calls would just
double the amount of work and ram needed.
(This is just error condition code, so this amount is not that relevant... but
it still cleans up the code)
Bert
}
return svn_error_createf(SVN_ERR_EXTERNAL_PROGRAM, NULL,
_('%s' was expanded to '%s' and returned
%d),
Re: C++ thoughts for Berlin
On 5/29/13 6:17 PM, Justin Erenkrantz wrote: On Wed, May 29, 2013 at 6:03 PM, Blair Zajac bl...@orcaware.com mailto:bl...@orcaware.com wrote: Yup, I've had lots of issues with this. Putting C++ pool wrappers in C++ classes and having them destroy in the correct order can be tricky to get right (lots of core dumps in our internal RPC server). One of the nice things about moving to C++, assuming we don't use pools, is that one could stop thinking about memory management. I don't see how you can have a clean C++ implementation as we expose pools in the C API. I just think we're going to bring a world of hurt upon us all if we try to do a wholesale rewrite of C++ and try to shove the pool model into it. (The batons and callbacks all require pools with a certain lifetime - so there are third-party code that is relying upon the pool hierarchy being correct.) If we really wanted to go that route, the far saner (if you can call it that) approach is to just call it Subversion 2.0 and have a pool-free external API...from where I sit, I don't see much value going that far - how many years do we want to dedicate to 2.0? Are things ultimately so broken that we simply can't make Subversion better unless we go to C++? It's not a zero-cost item. I agree it's not worth going to C++. Where I'm coming from is a frustration on the number of times I've seen pool lifetime bugs get fixed and it would be great to be in a language where one doesn't need to worry about that, or as much. Blair
Re: Media-Type for SVNPubSub
I was hoping someone else would weigh in here. But I guess not. On Tue, May 28, 2013 at 11:15 AM, Greg Stein gst...@gmail.com wrote: You guys are over-thinking it. Simply state this format is ASF-wide and be done with it. Okay but should we ask anyone before we go and start using something like application/vnd.apache.pubsub+json? Daniel seemed to think we shouldn't use the apache namespace without talking to operations. Media types are not born every month. More like one every few years. I'm even gonna guess most aren't registered with the IANA (tho I suggest we register ours). That's a fair point. So? That's what the registered definition is for: to explain the media type. No that is not the purpose of the registration. It's to provide a consistent unambiguous name for a format. The fact that it is descriptive is a side effect of our desire to make them human readable. Media-Types could have just as easily been opaque numbers. Are these obvious? application/vnd.svn-svndiff application/vnd.svn-skel Not really. But we just started using them. Yes assuming they were defined when Subversion was under the Subversion Corporation. Interestingly they appear not to be registered (at least they aren't on the IANA list). Anyway, you suggested: application/vnd.apache-subversion.pubsub-stream+json and I suggested: application/vnd.apache.pubsub+json cuz we don't need the -subversion in there. And the -stream will be inherent in the format. As you state: it is also generic, so no need for svnpubsub or whatever. For existing conventions (for whatever that's worth): http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types I'll note that a vnd.apache does not exist. So it's empirically true that per-project naming for conflict resolution isn't worthwhile. The desire to include the top level project name in there was to avoid stepping on any toes. If that's not an issue then we can remove it. I'm not so sure we can clearly drop the -stream, because technically SVNPubSub has two formats. The format between the server and the commit-hook and the format between the subscribers and the server. The commit-hook/server format is unambiguously JSON, so we're not bothering to talk about it. Without it I think which format you're talking about is ambiguous. (and we also don't need/want a media type that is freakishly long) Fair enough.
Re: C++ thoughts for Berlin
On Sat, Jun 01, 2013 at 04:23:22PM -0700, Blair Zajac wrote: I agree it's not worth going to C++. Where I'm coming from is a frustration on the number of times I've seen pool lifetime bugs get fixed and it would be great to be in a language where one doesn't need to worry about that, or as much. Maybe there's another way of discouraging those bugs? Perhaps we should run the test suite under valgrind, with APR pool debugging enabled, and clearing every scratch_pool parameter immediately after the call, on a regular basis? (I mean: wherever we have 'f(foo, pool, pool);', convert that to 's = svn_pool_create(pool); f(foo, s, pool); svn_pool_destroy(s);', then run 'make svnserveautocheck THREADED=1' under valgrind.)
Re: Media-Type for SVNPubSub
On Sat, Jun 01, 2013 at 07:07:10PM -0700, Ben Reser wrote: I was hoping someone else would weigh in here. But I guess not. On Tue, May 28, 2013 at 11:15 AM, Greg Stein gst...@gmail.com wrote: You guys are over-thinking it. Simply state this format is ASF-wide and be done with it. Okay but should we ask anyone before we go and start using something like application/vnd.apache.pubsub+json? Daniel seemed to think we shouldn't use the apache namespace without talking to operations. To clarify: the point here isn't to add red tape; the point is not to stomp on a shared namespace. In vnd.apache.pubsub, Apache Pubsub is neither a PMC nor a product. If any PMC registers arbitrary unix names of things in a shared namespace, the result would be confusing. Anyway, wrt concerns raised so far, I'll mention a few more permutations: application/vnd.svn-pubsub+json application/vnd.pubsub-stream+json application/vnd.svn-pubsub-stream+json
