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 05:54:18 GMT
>There seems to be three camps on the best way to create the Apache 2.0
>code base.
>
>Camp 1: Use the apache-mpm tree as the base. Merge 1.3.8 changes up into
>Apache 2.0.
>Dean, Ben L., Jim, Bill
>
>Camp 2: Use 1.3.8 as the base, then add MPM, HOOKS, APR, etc.
>Roy, Ken

Actually, what I said was that you'll want to do camp 1 stuff first
in any case, and camp 2 can happen when someone who cares about it
can do it.

>How important is it to maintain history? I don't see much point in it.
>Lets move apache-mpm into the top level apache-2.0 directory, merge in
>the 1.3.8 diffs then version all the files 1.1. 

The 1.3.x module has its own history.  The apr module has a mismash of
history that crosses six months of 1.3 maintenance with six months of
going back-and-forth on pthreads and apr.  The mpm is somewhere between,
but I have no idea where.

Building a clean repository performs two functions:

  1) it reduces the size of the repository and speeds CVS access
  2) it allows us to know what was changed

I know you guys well enough to say that a few of the IBMers and
Dean and probably BenL have a pretty good idea at this point what
might have been changed in the past to make today's 2.x, but probably
50% of a clue as to whether what was changed is still the way they remember
it after several repositories and multiple reworks.  And I'm pretty
damn sure you won't remember more than 10% of it a year from now.

I also know that, even though I've read your discussions and docs and
every single commit that was made, that I don't have a friggin clue what
the difference is between 1.3.8 and 2.x.  I've seen the same files
get hashed and rehashed five or six times each.  I've seen ideas pop back
and forth as to how various alternatives might work.  The only way I am
going to obtain that clue is by doing comparisons and inspecting the
history, and in order to do that within the scope of my individual
time-to-hack alotment that I get every once in a while, that history
has to be in the same repository as I am working.  It doesn't do me
any good to do diffs between trees, since the diffs don't tell me why
(what goal was served) by the change, and by the time I finished
analyzing the reconstructed diffs of multiple repositories I won't have
any time to do the work for which I needed to know the difference.

Whether or not the people currently working on that code think they need
a clean history breakpoint between 1.3.x and 2.0 is not relevant -- the
project needs it, and particularly those people that will take on the
task of maintaining this code after some of you guys move on to other
projects.  Don't think of it as a short-term cost -- think of it as the
number of questions you won't have to answer for the next three years.

In any case, as I said before, the clean repository can be done at any
time after mpm is merged up with 1.3.x and apr, provided that you folks
are willing to identify what changes are for what purpose given a
single large recursive diff between 1.3.8 and 2.x.

....Roy

Mime
View raw message