On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
Allan - your last patches were to try to -wedge- the current API into httpd. Can you share the patch just to fix APR? Then we can start to comprehend scope. NO CASTS - just the correct declarations in the first place.
Since this is obviously going to be big, don't you think it would be better to just get going on a sandbox branch of APR so that we can work iteratively instead of passing big patches back and forth?
I'm all for using branches if there's going to be some kind of long-term breakage caused by the change, but if we're certain that APR 2.0 is going to include these changes for 64 bit support in the API then I'd much rather see it happen in the trunk, with iterations of the change happening there. Long lived branches should be avoided, IMO, if at all possible. Doing the development that will lead to 2.0 on the trunk doesn't keep us from merging changes back into the 1.0.x branch when appropriate.
I guess I'm just arguing for a single branch that's the target of the current development, as opposed to one 64 bit dev branch and one trunk which holds other changes, thus requiring us to either invest constant effort in merging changes from the trunk into the 64 bit branch or letting it get kind of stale and then having a mega-huge merge into the trunk at the end.
-garrett
