Re: Windows build still requires apr-util?
Hi, On 13 March 2013 18:51, kmra...@rockwellcollins.com wrote: Doesn't Apache officially only support vc6 builds for httpd on Windows? The ASF supports no binaries at all. Indeed Bill used to compile httpd with VC6, but the plans are to go to newer compiler. You may have noticed that there weren't any windows binaries with the last releases. How ever Gregg Smith made the build files for 1.5.1 see http://mail-archives.apache.org/mod_mbox/apr-dev/201303.mbox/%3C513C5A5F.7010605%40gknw.net%3E Cheers Mario
Re: Windows build still requires apr-util?
On 13 March 2013 19:15, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: woensdag 13 maart 2013 18:47 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? Gentle reminder: VS 2010 doesn't compile the latest revision. Please, add #include time.h into subversion\libsvn_subr\win32_crashrpt.c and commit. I think that is somehow dependant on other settings as it just compiles for me with 2010 (and 2012 and 2008). Do you compile this file at all? Can you explain what makes your environment different You do not have SVN_USE_WIN32_CRASHHANDLER? You use different revision? (mine is 1456399) Open VS 2010 .sln, navigate to 'win32_crashrpt.c' in project 'libsvn_subr', choose Build-Compile. What do you see? I see this: 1-- Build started: Project: libsvn_subr (Libraries\libsvn_subr), Configuration: Debug Win32 -- 1Build started 14.03.2013 13:26:47. 1ClCompile: 1 win32_crashrpt.c 1..\..\..\subversion\libsvn_subr\win32_crashrpt.c(706): error C4013: 'time' undefined; assuming extern returning int 1..\..\..\subversion\libsvn_subr\win32_crashrpt.c(707): error C4013: 'strftime' undefined; assuming extern returning int 1..\..\..\subversion\libsvn_subr\win32_crashrpt.c(707): error C4013: 'localtime' undefined; assuming extern returning int 1 1Build FAILED. 1 1Time Elapsed 00:00:00.96 == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == , because just adding includes everywhere is not the way to fix these things Every translation unit with a call to localtime/time/strftime must include time.h. So it IS a way to fix these things.
Re: What's blocking the 1.8 branch?
On Wed, Mar 13, 2013 at 7:39 PM, Julian Foad julianf...@btopenworld.com wrote: Hey, all. The CollabNetters were talking today about the status of our codebase, and were trying to enumerate the things which are blocking the 1.8.x branch. [..] There are currently ten open issues marked '1.8.0', including some of the ones mentioned above. I suppose we don't necessarily need to fix such issues before branching? Maybe some of them should be demoted to '1.8-consider'? I think that issues #4329 and #4316 are the blocking ones. It will be much better if we could fix these two issues before the branch. Other issues marked '1.8.0' seems to be not such necessary for the branch. -- Ivan Zhakov
Re: svn commit: r1456394 - in /subversion/trunk/subversion/bindings/javahl/native: DiffOptions.cpp DiffOptions.h
On 14.03.2013 12:18, phi...@apache.org wrote: Author: philip Date: Thu Mar 14 11:18:56 2013 New Revision: 1456394 URL: http://svn.apache.org/r1456394 Log: Pass SVN:Pool by reference otherwise a subpool gets created/destroyed and the allocated memory becomes invalid. Yikes. Thanks for spotting that. Stuff doesn't crash on the Mac, or I'd have noticed ... -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: Consistency between 'update' and 'switch' APIs
On 03/13/2013 10:15 PM, Julian Foad wrote: The interesting case here is a file replaced with an identical file: that's the only case where it's unchanged if ignoring ancestry but otherwise it's changed. This may, in fact, be the only case that's interesting to our discussion. But I trust you realize that it's not mere file replacement that's affected here. Ignoring ancestry on the server side will transform directory replacements, too, converting them (editor-wise) into a normal open_directory() (perhaps with propchanges) where a full tree deletion+addition would normally have been transmitted. [Deferring further comment until we unearth the reasoning behind switch supporting --ignore-ancestry at all.] -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
RE: Windows build still requires apr-util?
-Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 13:33 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? On 13 March 2013 19:15, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: woensdag 13 maart 2013 18:47 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? Gentle reminder: VS 2010 doesn't compile the latest revision. Please, add #include time.h into subversion\libsvn_subr\win32_crashrpt.c and commit. I think that is somehow dependant on other settings as it just compiles for me with 2010 (and 2012 and 2008). Do you compile this file at all? Can you explain what makes your environment different You do not have SVN_USE_WIN32_CRASHHANDLER? You use different revision? (mine is 1456399) Open VS 2010 .sln, navigate to 'win32_crashrpt.c' in project 'libsvn_subr', choose Build-Compile. What do you see? I see this: 1-- Build started: Project: libsvn_subr (Libraries\libsvn_subr), Configuration: Debug Win32 -- 1Build started 14.03.2013 13:26:47. 1ClCompile: 1 win32_crashrpt.c 1..\..\..\subversion\libsvn_subr\win32_crashrpt.c(706): error C4013: 'time' undefined; assuming extern returning int 1..\..\..\subversion\libsvn_subr\win32_crashrpt.c(707): error C4013: 'strftime' undefined; assuming extern returning int 1..\..\..\subversion\libsvn_subr\win32_crashrpt.c(707): error C4013: 'localtime' undefined; assuming extern returning int 1 1Build FAILED. 1 1Time Elapsed 00:00:00.96 == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == , because just adding includes everywhere is not the way to fix these things Every translation unit with a call to localtime/time/strftime must include time.h. So it IS a way to fix these things. My apr.h includes time.h. apr.hw defines APR_HAVE_TIME and the generated apr.h then includes time.h for me. Why should we include this file manually? Bert
RE: What's blocking the 1.8 branch?
-Original Message- From: Ivan Zhakov [mailto:i...@visualsvn.com] Sent: donderdag 14 maart 2013 13:35 To: Julian Foad Cc: C. Michael Pilato; Subversion Development Subject: Re: What's blocking the 1.8 branch? On Wed, Mar 13, 2013 at 7:39 PM, Julian Foad julianf...@btopenworld.com wrote: Hey, all. The CollabNetters were talking today about the status of our codebase, and were trying to enumerate the things which are blocking the 1.8.x branch. [..] There are currently ten open issues marked '1.8.0', including some of the ones mentioned above. I suppose we don't necessarily need to fix such issues before branching? Maybe some of them should be demoted to '1.8- consider'? I think that issues #4329 and #4316 are the blocking ones. It will be much better if we could fix these two issues before the branch. http://subversion.tigris.org/issues/show_bug.cgi?id=4329 - automatic merge uses reintegrate type merge if source is fully synced http://subversion.tigris.org/issues/show_bug.cgi?id=4316 - Merge errors out after resolving conflicts Other issues marked '1.8.0' seems to be not such necessary for the branch. I just added issue 4336 for 1.8.0 as it allows getting your db in an inconsistent state: http://subversion.tigris.org/issues/show_bug.cgi?id=4336 - Handle incoming deletes via the update move editor doesn't add base-deleted (My guess would be that it isn't hard to fix this for someone familiar with this code) Bert
RE: Windows build still requires apr-util?
-Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 14:13 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 14 March 2013 13:44, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 13:31 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 13 March 2013 19:15, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: woensdag 13 maart 2013 18:47 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? Gentle reminder: VS 2010 doesn't compile the latest revision. Please, add #include time.h into subversion\libsvn_subr\win32_crashrpt.c and commit. I think that is somehow dependant on other settings as it just compiles for me with 2010 (and 2012 and 2008). Do not compile this file at all? Can you explain what makes your environment different You do not have SVN_USE_WIN32_CRASHHANDLER? You use different revision? (mine is 1456399) Open VS 2010 .sln, navigate to 'win32_crashrpt.c' in project 'libsvn_subr', choose Build-Compile. What do you see? I see this: I use the crash handler. (Standard settings) and I usually build Subversion trunk multiple times per day with different Visual Studio versions. The file hasn't changed in this respect for years. time.h is included by apr.h for me. My apr.h is attached. Can you compare it with yours? I don't see why we would have to duplicate the include here in my environment. Is time.h from apr.h guaranteed? Yes, in apr 0.9.X and 1.x it is always included on Windows, see apr.hw from the apr project. Their compatibility rules are the same as ours. We don't declare apr 2.X support in Subversion, so I would guess that is untested. But I would guess it is still included there. (And unless it was an actual decision to remove it, I would call it a bug if it is no longer included) But APR is supported on another mailinglist, than this one. Bert
Re: What's blocking the 1.8 branch?
On 03/14/2013 08:35 AM, Ivan Zhakov wrote: I think that issues #4329 and #4316 are the blocking ones. It will be much better if we could fix these two issues before the branch. I'm not trying to be contentious, but ... why before the branch? I guess if we thought the solutions would require major overhaul, lots of code churn -- in other words, that they'd be a pain to review and merge -- it would make sense to try to fix them before entering the Additional Process Zone. But is that the case for these? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: What's blocking the 1.8 branch?
On 03/14/2013 10:42 AM, C. Michael Pilato wrote: On 03/14/2013 08:35 AM, Ivan Zhakov wrote: I think that issues #4329 and #4316 are the blocking ones. It will be much better if we could fix these two issues before the branch. I'm not trying to be contentious, but ... why before the branch? I guess if we thought the solutions would require major overhaul, lots of code churn -- in other words, that they'd be a pain to review and merge -- it would make sense to try to fix them before entering the Additional Process Zone. But is that the case for these? Spoke too soon. I see elsethread that Julian does expect #4316 to be a bit more churny and agrees that this should happen before branching. I'm cool with that -- he is, after all, much closer to the merge code than I am. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Windows build still requires apr-util?
On 14 March 2013 15:00, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 14:13 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 14 March 2013 13:44, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 13:31 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 13 March 2013 19:15, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: woensdag 13 maart 2013 18:47 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? Gentle reminder: VS 2010 doesn't compile the latest revision. Please, add #include time.h into subversion\libsvn_subr\win32_crashrpt.c and commit. I think that is somehow dependant on other settings as it just compiles for me with 2010 (and 2012 and 2008). Do not compile this file at all? Can you explain what makes your environment different You do not have SVN_USE_WIN32_CRASHHANDLER? You use different revision? (mine is 1456399) Open VS 2010 .sln, navigate to 'win32_crashrpt.c' in project 'libsvn_subr', choose Build-Compile. What do you see? I see this: I use the crash handler. (Standard settings) and I usually build Subversion trunk multiple times per day with different Visual Studio versions. The file hasn't changed in this respect for years. time.h is included by apr.h for me. My apr.h is attached. Can you compare it with yours? I don't see why we would have to duplicate the include here in my environment. Is time.h from apr.h guaranteed? Yes Hard to believe. I don't know about apr specifically, but usually library headers (like apr.h) are means to deliver library's (i.e. APR's) functions/types/constants and not means to deliver system headers. And when they do, it is just a side effect. We don't declare apr 2.X support in Subversion, so I would guess that is untested. Didn't know about not supporting 2.X in subversion. Thanks for telling. It is not mentioned in 'INSTALL'. But I would guess it is still included there. I used apr 2.0. No time.h there, see the apr.h I sent you.
RE: Windows build still requires apr-util?
-Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 16:02 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? On 14 March 2013 15:00, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 14:13 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 14 March 2013 13:44, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 13:31 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 13 March 2013 19:15, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: woensdag 13 maart 2013 18:47 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? Gentle reminder: VS 2010 doesn't compile the latest revision. Please, add #include time.h into subversion\libsvn_subr\win32_crashrpt.c and commit. I think that is somehow dependant on other settings as it just compiles for me with 2010 (and 2012 and 2008). Do not compile this file at all? Can you explain what makes your environment different You do not have SVN_USE_WIN32_CRASHHANDLER? You use different revision? (mine is 1456399) Open VS 2010 .sln, navigate to 'win32_crashrpt.c' in project 'libsvn_subr', choose Build-Compile. What do you see? I see this: I use the crash handler. (Standard settings) and I usually build Subversion trunk multiple times per day with different Visual Studio versions. The file hasn't changed in this respect for years. time.h is included by apr.h for me. My apr.h is attached. Can you compare it with yours? I don't see why we would have to duplicate the include here in my environment. Is time.h from apr.h guaranteed? Yes Hard to believe. I don't know about apr specifically, but usually library headers (like apr.h) are means to deliver library's (i.e. APR's) functions/types/constants and not means to deliver system headers. And when they do, it is just a side effect. We don't declare apr 2.X support in Subversion, so I would guess that is untested. Didn't know about not supporting 2.X in subversion. Thanks for telling. It is not mentioned in 'INSTALL'. From the details section of INSTALL 1. Apache Portable Runtime 0.9.7 or 1.X.X (REQUIRED) Whenever you want to build any part of Subversion, you need the Apache Portable Runtime (APR) and the APR Utility (APR-util) libraries. Also note that there are no released apr 2.x versions on http://apr.apache.org/, the recommended version there is still 1.4.6. In the current state we haven't started adding 2.X compatibility, as officially it doesn't exist yet. (Anything can change until the first released 2.X. There are no compatibly promises between major versions) Bert
Re: Windows build still requires apr-util?
On 14 March 2013 16:09, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 16:02 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? On 14 March 2013 15:00, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 14:13 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 14 March 2013 13:44, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: donderdag 14 maart 2013 13:31 To: Bert Huijben Subject: Re: Windows build still requires apr-util? On 13 March 2013 19:15, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: Sergei Antonov [mailto:sap...@gmail.com] Sent: woensdag 13 maart 2013 18:47 To: dev@subversion.apache.org Subject: Re: Windows build still requires apr-util? Gentle reminder: VS 2010 doesn't compile the latest revision. Please, add #include time.h into subversion\libsvn_subr\win32_crashrpt.c and commit. I think that is somehow dependant on other settings as it just compiles for me with 2010 (and 2012 and 2008). Do not compile this file at all? Can you explain what makes your environment different You do not have SVN_USE_WIN32_CRASHHANDLER? You use different revision? (mine is 1456399) Open VS 2010 .sln, navigate to 'win32_crashrpt.c' in project 'libsvn_subr', choose Build-Compile. What do you see? I see this: I use the crash handler. (Standard settings) and I usually build Subversion trunk multiple times per day with different Visual Studio versions. The file hasn't changed in this respect for years. time.h is included by apr.h for me. My apr.h is attached. Can you compare it with yours? I don't see why we would have to duplicate the include here in my environment. Is time.h from apr.h guaranteed? Yes Hard to believe. I don't know about apr specifically, but usually library headers (like apr.h) are means to deliver library's (i.e. APR's) functions/types/constants and not means to deliver system headers. And when they do, it is just a side effect. We don't declare apr 2.X support in Subversion, so I would guess that is untested. Didn't know about not supporting 2.X in subversion. Thanks for telling. It is not mentioned in 'INSTALL'. From the details section of INSTALL 1. Apache Portable Runtime 0.9.7 or 1.X.X (REQUIRED) Whenever you want to build any part of Subversion, you need the Apache Portable Runtime (APR) and the APR Utility (APR-util) libraries. I compiled for Windows, so I went straight to E. Building the Latest Source under Windows of INSTALL, and read there: * Apache apr, apr-util, and optionally apr-iconv libraries, version 0.9.12 or later. Included in both the Subversion dependencies ZIP file or later - no upper limit. Also note that there are no released apr 2.x versions on http://apr.apache.org/, the recommended version there is still 1.4.6. Good. I've switched to 1.4.6.
Re: Windows build still requires apr-util?
On Thu, Mar 14, 2013 at 8:09 AM, Bert Huijben b...@qqmail.nl wrote: In the current state we haven't started adding 2.X compatibility, as officially it doesn't exist yet. (Anything can change until the first released 2.X. There are no compatibly promises between major versions) Unix build works with APR 2.x (mostly thanks to Philip). I've been using it off and on that way whenever I wanted to debug the full stack (apr/httpd/subversion). I haven't noticed any issues. At least for me I don't have time.h being included by apr.h in either APR 2.x or 1.x: $ egrep -i time.h /usr/include/apr-1.0/apr.h #define APR_HAVE_SYS_TIME_H 1 #define APR_HAVE_TIME_H 1 $ egrep -i time.h /home/breser/httpd-trunk-root/include/apr-2/apr.h #define APR_HAVE_SYS_TIME_H 1 #define APR_HAVE_TIME_H 1 It was removed from apr.hw in r892162 with the message futher win32 synchronization However, as Bert has already pointed out this is probably something that should be directed towards the APR dev list.
[RFC] Issue Tracker Cleanup
Whenever we approach a release we always face the question: Which of our open issues are blockers for the upcoming release? Obviously as we approach 1.8, anything with a target milestone of 1.8.0 is (supposedly) a blocker. But what about all the issues with the '---' target milestone? Very old issues (e.g. something filed in say 2007) are almost certainly not blockers, whereas more recently filed issues may be. Unfortunately we currently have 131 issues with a target milestone of '---', though given the age of many of these I'm fairly confident they are *not* blockers for 1.8 as they have already seen one or more releases pass by. Recall how we claim to use the target milestone: [[[ When an issue is first filed, it automatically goes in the --- target milestone, which indicates that the issue has not yet been processed. A developer will examine it and maybe talk to other developers, then estimate the bug's severity, the effort required to fix it, and schedule it in a numbered milestone, for example 1.1. (Or they may put it the unscheduled or nonblocking milestone, if they consider it tolerable for all currently planned releases.) An issue filed in unscheduled might still get fixed soon, if some committer decides they want it done. Putting it in unscheduled merely means it hasn't been scheduled for any particular release yet. The nonblocking milestone, on the other hand, means that we do not anticipate ever scheduling the issue for a particular release. This also does not mean the issue will never be fixed; it merely means that we don't plan to block any release on it. ]]] In the interests of sanity I propose we bulk assign all issues filed before some arbitrary point in time to the 'unscheduled' milestone. I suggest using the date 1.7.0 was tagged as that point, under the assumption that any issues filed prior were not considered 1.7.0 blockers, so shouldn't be considered 1.8.0 blockers either. That would leave 24 newer issues which I'm happy to review and assign an initial milestone to. Thoughts? -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
Re: [RFC] Issue Tracker Cleanup
Paul Burba wrote: Whenever we approach a release we always face the question: Which of our open issues are blockers for the upcoming release? Obviously as we approach 1.8, anything with a target milestone of 1.8.0 is (supposedly) a blocker. But what about all the issues with the '---' target milestone? Very old issues (e.g. something filed in say 2007) are almost certainly not blockers, whereas more recently filed issues may be. Unfortunately we currently have 131 issues with a target milestone of '---', though given the age of many of these I'm fairly confident they are *not* blockers for 1.8 as they have already seen one or more releases pass by. Recall how we claim to use the target milestone: [...] In the interests of sanity I propose we bulk assign all issues filed before some arbitrary point in time to the 'unscheduled' milestone. I suggest using the date 1.7.0 was tagged as that point, under the assumption that any issues filed prior were not considered 1.7.0 blockers, so shouldn't be considered 1.8.0 blockers either. That would leave 24 newer issues which I'm happy to review and assign an initial milestone to. Thoughts? +1, and I can't think of any date better that your suggestion of 1.7.0 tag date. - Julian
Re: svn commit: r1456636 - /subversion/trunk/subversion/svn/svn.c
On Thu, Mar 14, 2013 at 08:09:45PM -, julianf...@apache.org wrote:
Author: julianfoad
Date: Thu Mar 14 20:09:44 2013
New Revision: 1456636
URL: http://svn.apache.org/r1456636
Log:
* subversion/svn/svn.c
(svn_cl__cmd_table): In the help for 'svn resolve', add the missing value
'working' for the '--accept' option.
Modified:
subversion/trunk/subversion/svn/svn.c
Modified: subversion/trunk/subversion/svn/svn.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/svn.c?rev=1456636r1=1456635r2=1456636view=diff
==
--- subversion/trunk/subversion/svn/svn.c (original)
+++ subversion/trunk/subversion/svn/svn.c Thu Mar 14 20:09:44 2013
@@ -1343,7 +1343,7 @@ const svn_opt_subcommand_desc2_t svn_cl_
{opt_targets, 'R', opt_depth, 'q', opt_accept},
{{opt_accept, N_(specify automatic conflict resolution source\n
- ('base', 'working', 'mine-conflict',\n
^^^
+ ('working', 'base', 'working', 'mine-conflict',\n
^^^^^^
I don't understand this change. 'working' was already mentioned.
Was this a mistake?
'theirs-conflict', 'mine-full', 'theirs-full'))}} },
