httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ics.uci.edu>
Subject Re: Where to start the Apache 2.0 code base
Date Tue, 03 Aug 1999 22:46:59 GMT
>>    1.   merge in all work      1. cvs export 1.3.8
>
>What do you mean "all work". Do you mean the 1.3.8 work, or APRizing,
>or something completely different?

All of the work that you can do before 1.3.8 is released.  Attempting
to APRize the code before then would be silly given all the other things
that have to be done first, but even that can be worked around.  OTOH,
you could always work on getting 1.3.8 released instead.  The important
thing is that this should not, in any way, impede reasonable progress
on other fronts.

>>    2.   move files to final    2. move files so that the old files
>>         locations for dists       correspond to their final loc in mpm
>>    3.   continue hacking       3. cvs add all to form rev 1.1 == 1.3.8
>>    4.   tag as merge point     4. tag as APACHE_1_3_8_moved
>>    5.   continue hacking       5. diff -r APACHE_1_3_8_moved mpm_merge_point
>>    6.   identify diffs from scratch as change sets
>>                                7. merge diffs as complete change sets
>>    8.   move mpm to archive    8. merge changes after mpm merge point
>>                                9. move scratch rcs files to 2.0 directory
>
>I agree that step 6 is useful, but is it feasible? (This is
>not a rhetorical question, I'm seriously asking.) Quite a few files
>have been completely rewritten between apache-1.3 and MPM.

Sure, it isn't too hard.  Almost all of the mpm/pthreads changes
were in the core, affecting the same files for the same purposes, and
thus can be treated as one change set.  All of the hook mods are one
change set.  Everything else can be identified by looking at the history
log of the apr/mpm repositories, or asked on this list.  If that isn't
sufficient to identify a change, then we have a serious problem anyway.

Applying them back to the clean repository is even easier, assuming
that they are complete and the 1.3.x changes are fully merged into
the mpm tree.

I can do this stuff.  What I need is for you guys to do the easy things
first rather than making a bunch of APR changes before you even have a
working repository (meaning a complete directory tree that can be quickly
configured/installed/tested on the platforms that the rest of us use).
The key is to get all the files (or as much as possible) located in the
right places *first*, within any repository, so that later changes can
be cleanly applied based on the history log.  Once that is done and the
last changes from 1.3.8 merged in, you can tag the merge point and
make any changes you might desire -- they will simply be re-synced
from the history log later.  Let me worry about the clean repository.

....Roy

Mime
View raw message