Re: svn commit: r106038 - in apr/apr/branches: 0.9.x APR_0_9_BRANCH
[EMAIL PROTECTED] wrote: Author: wrowe Date: Sat Nov 20 14:46:04 2004 New Revision: 106038 Added: apr/apr/branches/0.9.x/ - copied from r106037, apr/apr/branches/APR_0_9_BRANCH/ Removed: apr/apr/branches/APR_0_9_BRANCH/ Log: Reorganize the apr project 0.9 branches Quick question (I *know* I should have hit at least one SVN preso/BOF @ Ac2004, but there it is): if I already checked-out the APR_0_9_BRANCH, how do I change it, locally, to the 0.9.x one? I don't have to re-checkout, do I? Also, more a generic question, why didn't we svn move instead of cvn copy ?
Re: svn commit: r106038 - in apr/apr/branches: 0.9.x APR_0_9_BRANCH
Jim Jagielski wrote: [EMAIL PROTECTED] wrote: Author: wrowe Date: Sat Nov 20 14:46:04 2004 New Revision: 106038 Added: apr/apr/branches/0.9.x/ - copied from r106037, apr/apr/branches/APR_0_9_BRANCH/ Removed: apr/apr/branches/APR_0_9_BRANCH/ Log: Reorganize the apr project 0.9 branches Quick question (I *know* I should have hit at least one SVN preso/BOF @ Ac2004, but there it is): if I already checked-out the APR_0_9_BRANCH, how do I change it, locally, to the 0.9.x one? I don't have to re-checkout, do I? Nope: svn switch --help (from inside your working copy) svn switch https://svn.apache.org/repos/asf/apr/apr/branches/0.9.x Also, more a generic question, why didn't we svn move instead of cvn copy ? a svn 'move' currently is implemented as a copy and then rm of the old location.
Re: svn commit: r106038 - in apr/apr/branches: 0.9.x APR_0_9_BRANCH
* Jim Jagielski [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Author: wrowe Date: Sat Nov 20 14:46:04 2004 New Revision: 106038 Added: apr/apr/branches/0.9.x/ - copied from r106037, apr/apr/branches/APR_0_9_BRANCH/ Removed: apr/apr/branches/APR_0_9_BRANCH/ Log: Reorganize the apr project 0.9 branches Quick question (I *know* I should have hit at least one SVN preso/BOF @ Ac2004, but there it is): if I already checked-out the APR_0_9_BRANCH, how do I change it, locally, to the 0.9.x one? I don't have to re-checkout, do I? See OtherBill's posting on [EMAIL PROTECTED] You just need to svn switch. Also, more a generic question, why didn't we svn move instead of cvn copy ? move := copy delete (but atomic) nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: svn commit: r106038 - in apr/apr/branches: 0.9.x APR_0_9_BRANCH
At 07:10 PM 11/20/2004, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: Author: wrowe Date: Sat Nov 20 14:46:04 2004 New Revision: 106038 Added: apr/apr/branches/0.9.x/ - copied from r106037, apr/apr/branches/APR_0_9_BRANCH/ Removed: apr/apr/branches/APR_0_9_BRANCH/ Log: Reorganize the apr project 0.9 branches Quick question (I *know* I should have hit at least one SVN preso/BOF @ Ac2004, but there it is): if I already checked-out the APR_0_9_BRANCH, how do I change it, locally, to the 0.9.x one? I don't have to re-checkout, do I? Nope - that's one happy detail svn considered; see the post Subject: [SVN] Branches for apr[-util|-iconv] 0.9.x moved for details of how to switch. Also, more a generic question, why didn't we svn move instead of cvn copy ? We did, that's how the commit message appears (copy foo from bar, removed bar.) Bill
Re: svn commit: r105961 - apr/apr-util/trunk
Author: jorton Date: Sat Nov 20 05:17:18 2004 New Revision: 105961 Modified: apr/apr-util/trunk/CHANGES apr/apr-util/trunk/Makefile.in apr/apr-util/trunk/configure.in Log: Link libaprutil against the libraries on which it depends (dropping support for libtool 1.3): * configure.in: Remove EXTRA_OS_LINK export. * Makefile.in: Link target against APRUTIL_LIBS. PR: 11122 Could this be backported to 0.9.x, please? Thanks, Max.
Re: svn commit: r105961 - apr/apr-util/trunk
At 07:41 AM 11/21/2004, Max Bowsher wrote: Author: jorton Date: Sat Nov 20 05:17:18 2004 New Revision: 105961 Modified: apr/apr-util/trunk/CHANGES apr/apr-util/trunk/Makefile.in apr/apr-util/trunk/configure.in Log: Link libaprutil against the libraries on which it depends (dropping support for libtool 1.3): * configure.in: Remove EXTRA_OS_LINK export. * Makefile.in: Link target against APRUTIL_LIBS. PR: 11122 Could this be backported to 0.9.x, please? Most unlikely, as we supported libtool 1.3 throughout apr 0.9. More likely, we add a disclaimer with 1.x.x releases proclaiming 'you must use libtool 1.4'. I don't believe 1.x.x has been around long enough for this to affect end users. (Developers, yes, but I don't worry nearly as much about them.) Offer up a patch that doesn't break libtool 1.3 and I'd review. Bill
Re: More informative SVN subject line (Re: svn commit: r76284 - apr/apr/trunk)
Brad Nicholes wrote: I understand about the revision numbers and I agree that it is an important piece of information, but unnecessary on the subject line. The subject line needs to include information that allows one to quickly sort and prioritize the commits. IMHO, the revision number isn't a piece of information that helps do that. Once I have determined that the commit is important enough for me to review, I will certainly open and view the contents of the message. After I have reviewed the commit via the message contents and determined that further review is necessary, that is the point when the revision number becomes *very* important. Hm. So would you then remember to add the revision number to the subject line in replies? In my experience, the revision number aids visual threading, whereas the list of changed files is mostly just junk once a conversation about a particular commit gets started. As far as the svn commit: prefix is concerned, it was redundant information before and I believe that it is still redundant information. Perhaps svn: is all that would be required so that when a commit message is replied to on the dev@ lists, it is distinguished from other posts. There's svn commit: and svn propchange:, so the commit isn't quite redundant. I suppose svn: and svn propchange: are different enough, though, especially as there will (hopefully) be many more commits than propchanges. -- Brane
win32 questions
I'm playing around with autogenerating dsp files again, and ran into a few weird things I wanted to ask about... First of all, threadproc/win32/threadcancel.c doesn't seem to be built. Or to be finished for that matter, the only function in there that isn't commented out is ap_cancel_thread, which clearly isn't an apr function. There doesn't seem to be any thread cancellation support anywhere else in APR, so can we just delete this file? Second, I notice in apr.dsp we explicitly exclude misc/win32/apr_app.c from being built, which makes sense, since you clearly don't want it in the library all the time. Is it absolutely necessary for apr.dsp to exclude it, or can we get away with just not listing it? Third, there are a bunch of header files (apr_random.h, arch/win32/apr_arch_proc_mutex.h, arch/win32/apr_arch_thread_cond.h, and arch/win32/apr_dbg_win32_handles.h specifically) that aren't listed in apr.dsp but do exist in the tree and one (apr_private_common.h) that doesn't exist but is listed. Any reason this can't be resynched with reality? Finally, it seems that the random/unix/*.c code is built as part of apr.dsp (the static lib) but not as part of libapr.dsp (the dll), is there a reason for this? Thanks, -garrett
Re: win32 questions
Garrett Rooney wrote: I'm playing around with autogenerating dsp files again, and ran into a few weird things I wanted to ask about... First of all, threadproc/win32/threadcancel.c doesn't seem to be built. Or to be finished for that matter, the only function in there that isn't commented out is ap_cancel_thread, which clearly isn't an apr function. There doesn't seem to be any thread cancellation support anywhere else in APR, so can we just delete this file? I'd say yes. We can always ressurect it if it becomes interesting. Second, I notice in apr.dsp we explicitly exclude misc/win32/apr_app.c from being built, which makes sense, since you clearly don't want it in the library all the time. Is it absolutely necessary for apr.dsp to exclude it, or can we get away with just not listing it? Not listing it is enough. Third, there are a bunch of header files (apr_random.h, arch/win32/apr_arch_proc_mutex.h, arch/win32/apr_arch_thread_cond.h, and arch/win32/apr_dbg_win32_handles.h specifically) that aren't listed in apr.dsp but do exist in the tree and one (apr_private_common.h) that doesn't exist but is listed. Any reason this can't be resynched with reality? apr_private_common.h certainly does exist. It's in include/arch. The others should be added to the .dsp. Finally, it seems that the random/unix/*.c code is built as part of apr.dsp (the static lib) but not as part of libapr.dsp (the dll), is there a reason for this? Sounds like a bug to me. I wonder how come nobody has noticed yet. -- Brane
Re: win32 questions
Branko ibej wrote: Garrett Rooney wrote: I'm playing around with autogenerating dsp files again, and ran into a few weird things I wanted to ask about... First of all, threadproc/win32/threadcancel.c doesn't seem to be built. Or to be finished for that matter, the only function in there that isn't commented out is ap_cancel_thread, which clearly isn't an apr function. There doesn't seem to be any thread cancellation support anywhere else in APR, so can we just delete this file? I'd say yes. We can always ressurect it if it becomes interesting. Cool, well if someone who has commit access could do that, I'd appreciate it. Second, I notice in apr.dsp we explicitly exclude misc/win32/apr_app.c from being built, which makes sense, since you clearly don't want it in the library all the time. Is it absolutely necessary for apr.dsp to exclude it, or can we get away with just not listing it? Not listing it is enough. Good to know. Third, there are a bunch of header files (apr_random.h, arch/win32/apr_arch_proc_mutex.h, arch/win32/apr_arch_thread_cond.h, and arch/win32/apr_dbg_win32_handles.h specifically) that aren't listed in apr.dsp but do exist in the tree and one (apr_private_common.h) that doesn't exist but is listed. Any reason this can't be resynched with reality? apr_private_common.h certainly does exist. It's in include/arch. The others should be added to the .dsp. Ahh, I just can't read then ;-) Finally, it seems that the random/unix/*.c code is built as part of apr.dsp (the static lib) but not as part of libapr.dsp (the dll), is there a reason for this? Sounds like a bug to me. I wonder how come nobody has noticed yet. Maybe nobody uses the dlls. Or nobody uses the random number generator. It is rather new, after all. In any case, this means I should have something that can generate apr.dsp and libapr.dsp later tonight or tomorrow. No promises as to how much it'll actually work, since I don't actually have a copy of VC6, but it'll at least look similar enough to the existing ones in the tree that someone on win32 will have a fighting chance to pound it into working order and commit it. Thanks, -garrett
Re: win32 questions
Garrett Rooney wrote: Branko ibej wrote: I'd say yes. We can always ressurect it if it becomes interesting. Cool, well if someone who has commit access could do that, I'd appreciate it. /me picks up his magic wand... and finds there's also a threadproc/beos/threadcancel.c, whereupon he decides to wait for further responses before removing both. Neither seems to be mentioned in any build scripts, though. Sounds like a bug to me. I wonder how come nobody has noticed yet. Maybe nobody uses the dlls. httpd uses the DLLs. :-) Or nobody uses the random number generator. It is rather new, after all. That's more likely, yes. In any case, this means I should have something that can generate apr.dsp and libapr.dsp later tonight or tomorrow. No promises as to how much it'll actually work, since I don't actually have a copy of VC6, but it'll at least look similar enough to the existing ones in the tree that someone on win32 will have a fighting chance to pound it into working order and commit it. Wonderful. I'll see if I can find some time to test the generator. -- Brane
Re: win32 questions
Branko ibej wrote: Cool, well if someone who has commit access could do that, I'd appreciate it. /me picks up his magic wand... and finds there's also a threadproc/beos/threadcancel.c, whereupon he decides to wait for further responses before removing both. Neither seems to be mentioned in any build scripts, though. Yeah, and both are old enough that they still have the 1.1 license at the top. I wonder why they were missed when the conversion happened. At first I assumed it was a bug in the cvs2svn conversion or something, but they still exist in the CVS repository, so that doesn't seem likely... In any case, this means I should have something that can generate apr.dsp and libapr.dsp later tonight or tomorrow. No promises as to how much it'll actually work, since I don't actually have a copy of VC6, but it'll at least look similar enough to the existing ones in the tree that someone on win32 will have a fighting chance to pound it into working order and commit it. Wonderful. I'll see if I can find some time to test the generator. Great, thanks. -garrett
