I see a lot of frustration going on. The thing is, httpd's
development process is nearly identical to Subversion's process... we
stole most of it from you folks! So why all the angst in httpd-land,
but not in Subversion-land?
I see two differences:
(A) New trunk releases happen often.
[[[
Fix typo in manual.
* docs/manual/logs.xml: typo. flexibly--flexible.
]]]
Index: docs/manual/logs.xml
===
--- docs/manual/logs.xml(revision 231041)
+++ docs/manual/logs.xml(working copy)
@@ -425,7 +425,7 @@
On May 26, 2005, at 10:11 PM, Greg Stein wrote:
1. We want mod_dav_svn to handle POST requests.
[...] I'm a bit wary of a vtable hook that merely gateways an
arbitrary set of functionality. Further, it would not belong to the
vsn_hooks vtable -- that is for DeltaV stuff which POST is most
There are few 'hacks' in Subversion right now to deal with problems
with mod_dav's API. There are also a couple of new Subversion issues
that could be solved with further hacks, but would be better remedied
through a mod_dav API change.
These things are documented here:
On May 8, 2005, at 3:15 PM, Olaf van der Spek wrote:
On 5/8/05, Phillip Susi [EMAIL PROTECTED] wrote:
I like this idea. I think one of the best and most important things
that apache is doing these days is trying to migrate away from
being a
web server and towards a generic server platform.
On Apr 21, 2005, at 9:29 AM, Fenlason, Josh wrote:
I was just wondering if the 2.0.54 Windows source will be available
soon. Thanks.
,
Josh.
It's sitting in http://apache.mirrors.versehost.com/httpd/ ?
On Apr 8, 2005, at 5:27 AM, NormW wrote:
Greetings All,
Just trying a build of SVN 1.2-rc1 with Apache2.0/2.1 and, AFAICT, it
seems .\modules\dav\main\dav.imp needs 'dav_get_locktoken_list'.
Is this related to this FAQ?
http://subversion.tigris.org/faq.html#windows-mod_dav_svn-build
On Apr 3, 2005, at 7:57 PM, Greg Stein wrote:
On Sun, Apr 03, 2005 at 01:58:56PM -0400, Joshua Slive wrote:
Does someone with a high-traffic, general-interest web site want to
take a
look through their logs for these user-agent strings.
I, uh, have just a few logs that I can scan. ;-)
Showoff.
On Feb 24, 2005, at 1:52 AM, Justin Erenkrantz wrote:
--On Wednesday, February 23, 2005 10:37 PM -0600 William A. Rowe,
Jr. [EMAIL PROTECTED] wrote:
Uhm, no. By that definition, all the pollution spewed from typical
Linux libraries would be considered 'public api.' Other platforms
are using
On Feb 22, 2005, at 8:07 PM, Branko ibej wrote:
The attached patch (against the 2.0.x branch) fixes the problem.
Shouldn't this patch be applied to *both* the 2.0 and 2.2 httpd lines?
Does that mean applying to httpd /trunk, then backporting to the 2.0
branch?
On Feb 23, 2005, at 2:12 PM, Justin Erenkrantz wrote:
That's been 'broken' forever and it's only because Subversion 1.2
wants to use private mod_dav functions.
They're not private mod_dav functions. They're supposedly a public
API, meant to be used by mod_dav provider back-ends. They just
I've been implementing new locking features in subversion lately, and
running into bits of pain here and there with mod_dav's provider API.
After some discussion with gstein and jerenkrantz, we're thinking about
revving the provider API to alleviate the pain.
Because mod_dav.h is a public
On Tue, 2004-06-15 at 10:29, Guenter Knauf wrote:
Hi,
does somebody know if its possible to move a file from one dir to
another without loosing the history?
With CVS, you must have an administrator hand-move the RCS file in the
repository. (Of course, then nothing records the fact that the
On Sun, 2004-05-23 at 15:01, Manoj Kasichainula wrote:
Sounds good. We should ponder a way to set up closed branches for
security patches. Maybe they could be protected on a case-by-case basis,
or we create a 4th top-level directory security-patches.
Woo. I just wanted to point out how
On Mon, 2004-03-15 at 12:02, Joshua Slive wrote:
Disadvantages of moving to subversion:
- Not as portable (?)
(Subversion clients/servers run anywhere APR does. I think that's
actually more portable than CVS, since I don't believe CVS pserver runs
on win32 at all.)
On Fri, 2004-01-23 at 08:07, Joe Orton wrote:
Nice, this is easy enough to reproduce. It only fills up because the
httpd children all have the read end of the pipe open, which is a bug in
itself. Applying below ensures that the pipe gets closed when the piped
logger exits, and so writes()
After a couple days of research (and talking with Ed Korthof), I think
the mysterious bug is solved. Recall the reproduction recipe:
* start a long running 'svn import'
* run 'apachectl graceful'
* a few seconds later, httpd just hangs.
It looks like the main bug is with the 'rotatelogs'
On Wed, 2004-01-21 at 04:29, Joe Orton wrote:
$ sudo strace -p 3850
trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
detach: ptrace(PTRACE_DETACH, ...): Operation not permitted
Ah, add CoreDumpDirectory /tmp to your httpd.conf and make sure you're
running the latest errata
On Wed, 2004-01-21 at 11:26, Joe Orton wrote:
By doing graceful restarts every few seconds during a large import, I
could reproduce a hang using ra_dav both over SSL or over plain HTTP to
a 0.36.0 server running on the localhost, when using DB 4.1.25. I've
upgraded to 4.2.52 and I can no
Sorry to be so slow in getting back to you, Joe. I'm still desperately
looking for a clue on this SSL hang that happens when I run 'apachectl
graceful'.
On Wed, 2004-01-14 at 15:51, Joe Orton wrote:
The client is hanging on a select() call:
What's the server doing?
Hm, I can't seem to
On Tue, 2004-01-13 at 17:26, Joe Orton wrote:
Is there still a TCP connection between the client and server at this
point? If so, you can identify the server child in question via the
server-status output or netstat -pt, and strace the process to see
what it's doing.
After the hang,
Hello, Apache folk. After showing this bug to gstein, iholsman, and
others in IRC, I fear I may have found a real bug. It has something
to do with SSL, but it's not clear whether this is a bug in the Neon
library, OpenSSL, mod_ssl, or httpd itself.
Client is: Redhat 9, svn 0.36.0 using neon
On Sun, 2003-11-16 at 11:11, Jeff Trawick wrote:
- patch management
many patches posted to this list or the bug db languish in limbo.
Very little happens until a core contributor decides to take over a patch
(more often than not it is more than simply shepherding it)
Little
gstein (and others), here is another micro-patch for the original
mod_dav.c 1.94 change we made a couple of weeks ago. David Waite
noticed a segfault and made this patch. Please apply ASAP!
The old code never hit this problem, because it would always send NULL
as the last argument to
OK, so now all the mod_dav 'streamy propfind' patches are in. My two
original concerns are addressed: no more segfault, no more unlogged
errors. I think jerenkrantz should be happy. gstein and striker as
well.
That said, it'd be swell if we can get revisions 1.94, 1.95, 1.96 of
mod_dav.c
[Reposting patch, with gstein's added check for r-sent_bodyct.]
Have mod_dav deal with errors that happen during a streamy provider response.
* mod_dav.c (dav_method_propfind, dav_method_report): if the dav
provider throws an error in the middle of streaming a response, have
mod_dav log an
Have mod_dav deal with errors that happen during a streamy provider response.
(This is a followup to the change that makes dav_method_propfind streamy.)
Hopefully, this addresses jerenkrantz's concerns; gstein and I can't
come up with a better solution, given the limits of HTTP design.
*
mod_dav improvement: make dav_method_propfind stream its response,
rather than cache every response object and send the whole 207 at once.
This patch has already gone through one iteration of review by gstein.
Note: this patch doesn't affect the mod_dav provider API at all.
Providers still
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
1. revamp mod_dav's use of pools internally.
This means adding pool arguments to the various layers of
function calls within mod_dav. Each caller controls subpool
creation, and possibly passes a subpool into a subordinate function
Sander Striker [EMAIL PROTECTED] writes:
Let's hope Ben stays interested ;). Even after he now discovered
the issue isn't that big for Subversion anymore... :) :) [Hi Ben]
Yeah... I just mentioned this on the Subversion dev list.
Basically, it looks like the emergency memory-usage problem no
Hi, I'm a new subscriber to this list, but not a complete stranger
either. My name is Ben Collins-Sussman, and I'm one of the original
Subversion developers. I'm also an APR committer, and well... I know
a whole lot of people on this list, and met many more of you at the
last Apachecon.
I'm
lines, and then run
./config.status by hand to finish creating the Makefiles. But this
workaround is getting awfully old. :-)
-Ben Collins-Sussman
[EMAIL PROTECTED]
32 matches
Mail list logo
