You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/08/30 18:47:28 UTC
2.1 repository?
Okay, now that OtherBill weighed in, I guess I'd like to start on
the 2.1 branch. Now, how to achieve this?
I think housing a branch under the httpd-2.0 CVS repository isn't
ideal for several reasons:
- As OtherBill pointed out, HEAD must remain 2.0.
- Our past strategy seems to have been that we create separate
repositories for each minor bump.
- If we ignore this and still branch for 2.1, that means we have 2.1
under the httpd-2.0 repository. Can I say "ick" loud enough?
- Therefore, I think we should create a httpd-2.1 repository.
And, I'd like to seriously consider using Subversion rather than CVS.
To me, it makes a lot of sense to switch to Subversion now rather
than later. If we do start on a model where we 'branch early and
often,' Subversion can handle the branching in a much better way
than CVS can (and more scalable to boot).
Since one of the primary matters in this 2.1 proposal is a re-org of
certain directories, we can handle moving files without losing
revision history. Something that is painful to do in CVS.
I've used Subversion enough and I believe it is certainly up to
handling our needs. If you haven't seen it yet, check out:
http://subversion.tigris.org/
Of course, I volunteer to maintain the server on icarus (I already
have the relevant permissions to do so).
I'm not saying that we have to use Subversion, but I think it is
definitely worth considering if we go to a new repos. -- justin
Re: 2.1 repository?
Posted by rb...@apache.org.
> [...]
> > Look at all of the repositories we created that are still left
> > around:
> >
> > apache-1.2
> > apache-1.3
> > apache-apr
> > apache-nspr
> > httpd-2.0
> >
> > The apache-apr and apache-nspr repositories were fairly short-lived.
> > I wasn't around when they were created, so perhaps the intention
> > really was that they would be the 'next big thing.'
>
> Not sure about apache-apr, but IIRC apache-nspr was a combination of
> "next big thing" and "sandbox for trying out this fancy styff".
apache-nspr was Dean's attept at Apache 2.0, but it was corrupted by the
NSPR license. Apache-apr was Manoj, Bill, and my first attempt at Apache
2.0 with APR. Both repositories were meant to become Apache 2.0, and both
include MANY lessons learned while introducing threads into Apache.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: 2.1 repository?
Posted by Ask Bjoern Hansen <as...@develooper.com>.
On Fri, 30 Aug 2002, Justin Erenkrantz wrote:
> >(leaving 2.0 as head, so nobody following older checkout instructions to
> >grab the now-current version have a 'surprize' in store.)
>
> I tend to find myself agreeing with him on this.
As Marc pointed out, that won't work with CVS.
> And, because I think it is very counter-intuitive if I check out
> httpd-2.0 and get "2.1" - something isn't right there.
I'm sure you'll be able to grok that. Alternately the repository
could be renamed to httpd-2 (as you almost suggested yourself).
[...]
> Look at all of the repositories we created that are still left
> around:
>
> apache-1.2
> apache-1.3
> apache-apr
> apache-nspr
> httpd-2.0
>
> The apache-apr and apache-nspr repositories were fairly short-lived.
> I wasn't around when they were created, so perhaps the intention
> really was that they would be the 'next big thing.'
Not sure about apache-apr, but IIRC apache-nspr was a combination of
"next big thing" and "sandbox for trying out this fancy styff".
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: 2.1 repository?
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Aug 30, 2002 at 10:27:18AM -0700, Aaron Bannert wrote:
> On Fri, Aug 30, 2002 at 09:47:28AM -0700, Justin Erenkrantz wrote:
> > - As OtherBill pointed out, HEAD must remain 2.0.
>
> Maybe HEAD should be the development trunk, while we branch off
> minor (and patch) revisions for stabalization.
I was referring to OtherBill's earlier comment today when he said:
>(leaving 2.0 as head, so nobody following older checkout instructions to
>grab the now-current version have a 'surprize' in store.)
I tend to find myself agreeing with him on this. And, because I
think it is very counter-intuitive if I check out httpd-2.0 and get
"2.1" - something isn't right there.
> Well, not exactly. It seems to be more based on the number of years
> we'll be working on that repository. I'd rather see us only create
> new repos for major revisions, then for feature revisions (aka minor
> bumps, like 2.0-->2.1 for the auth stuff) then we just do a cvs branch.
Look at all of the repositories we created that are still left
around:
apache-1.2
apache-1.3
apache-apr
apache-nspr
httpd-2.0
The apache-apr and apache-nspr repositories were fairly short-lived.
I wasn't around when they were created, so perhaps the intention
really was that they would be the 'next big thing.'
> > - If we ignore this and still branch for 2.1, that means we have 2.1
> > under the httpd-2.0 repository. Can I say "ick" loud enough?
>
> That's just for us, who cares?
Nope - any developers have to deal with this to. I think it's
general badness.
If it were called httpd-2, I'd be okay, but not httpd-2.0.
> > - Therefore, I think we should create a httpd-2.1 repository.
>
> -0.5 Simply for the reason that I see us working on 2.1 for 4 months, then
> continuing on to 2.2 for the next medium-big feature change.
Which is partly why I think we should move to Subversion -
repeated merges or not.
> A strong (non veto) -1 until subversion is 1.0 GA. Although I'd really
> like to see us using Subversion, I don't think we can afford to have
> any problems with the httpd project's code repositories.
Subversion has been self-hosting for a year now with zero data loss.
I'm not concerned.
> Yup, I agree, but that's something we're going to have to live with
> just a little longer, methinks.
I'm merely stating that we don't have to. Especially considering
the first order of business in a (proposed) 2.1 would be moving
files around. -- justin
Re: 2.1 repository?
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 30, 2002 at 10:27:18AM -0700, Aaron Bannert wrote:
> On Fri, Aug 30, 2002 at 09:47:28AM -0700, Justin Erenkrantz wrote:
> > - As OtherBill pointed out, HEAD must remain 2.0.
>
> Maybe HEAD should be the development trunk, while we branch off
> minor (and patch) revisions for stabalization.
>
> Like this:
>
> HEAD
> | HTTPD_2_0
> | /
> | /-----HTTPD_2_0_43
> | /
> | /-----HTTPD_2_0_42
> | /
> | /-----HTTPD_2_0_41
> | /
> |/
> |
> |
Absolutely. IMO, that is the only/best way to do this within CVS. We don't
have these kinds of restrictions/silliness in SVN, thankfully. It is really
frickin' obvious what you're checking out, as it is part of the path:
$ svn co http://svn.apache.org/httpd/httpd-2.0
or
$ svn co http://svn.apache.org/httpd/httpd-1.3
> > - Our past strategy seems to have been that we create separate
> > repositories for each minor bump.
>
> Well, not exactly. It seems to be more based on the number of years
> we'll be working on that repository. I'd rather see us only create
> new repos for major revisions, then for feature revisions (aka minor
> bumps, like 2.0-->2.1 for the auth stuff) then we just do a cvs branch.
Nah. Actually, I think a good amount is fear of CVS branches and some of the
pain that entails.
> > - If we ignore this and still branch for 2.1, that means we have 2.1
> > under the httpd-2.0 repository. Can I say "ick" loud enough?
>
> That's just for us, who cares?
There are a lot more people looking at the repository than just the
developers.
>...
> > And, I'd like to seriously consider using Subversion rather than CVS.
> > To me, it makes a lot of sense to switch to Subversion now rather
> > than later. If we do start on a model where we 'branch early and
> > often,' Subversion can handle the branching in a much better way
> > than CVS can (and more scalable to boot).
>
> A strong (non veto) -1 until subversion is 1.0 GA. Although I'd really
> like to see us using Subversion, I don't think we can afford to have
> any problems with the httpd project's code repositories.
Heh. Get real :-) As of today, Subversion has been self-hosting for exactly
one year. There has never been a single incident of data loss. Not even a
near miss [where the developers had to extract data]. Sure, we call
ourselves alpha, but we are *way* past that if you use that label in typical
terms. But with a revision control system, you have to *trust* the thing. So
we stay back at alpha.
Personally, I would love to see Subversion used. It will make our lives a
lot easier.
hehe... /me envisions Justin forking the codebase and putting it into his
own SVN server.
To be honest, I'm of a mixed mind for moving to SVN. While it would make a
lot of stuff hella easier, we don't have ViewSVN just yet. Also, I want to
load *all* the httpd software into the thing. I'm talking the apache-1.2
tree, apache-nspr, etc. One big mother of a CVS conversion, but also the
best part: get the loading done such that we have the actual copies and
branch points recorded. With enough upfront work, we can actually record
every move of files, the exact revisions where we forked off the 2.0
repository. etc. From a historical standpoint, that would rock. You could
see the complete evolution of modules/http/http_protocol.c since day one.
I'd also like to see the other httpd subprojects in there, but that isn't as
big of a deal. They don't have the history, forking, branching that the core
httpd has. But httpd-proxy does, so it would be a nice win to see when it
forked out, got dev'd hard, then brought back in.
> > Since one of the primary matters in this 2.1 proposal is a re-org of
> > certain directories, we can handle moving files without losing
> > revision history. Something that is painful to do in CVS.
>
> Yup, I agree, but that's something we're going to have to live with
> just a little longer, methinks.
Well, it sucks in CVS, needless to say, which is one reason that I like the
idea of switching to SVN. Of course, we can always extract these changes
when we do the repository conversions.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.1 repository?
Posted by Marc Slemko <ma...@znep.com>.
On Fri, 30 Aug 2002, Aaron Bannert wrote:
> On Fri, Aug 30, 2002 at 09:47:28AM -0700, Justin Erenkrantz wrote:
> > - As OtherBill pointed out, HEAD must remain 2.0.
>
> Maybe HEAD should be the development trunk, while we branch off
> minor (and patch) revisions for stabalization.
HEAD needs to be the main development branch due to the way CVS
works.
Retrieving any version other than HEAD out of the repository requires
patching back to the branchpoint, then forward along the branch.
This means that you want branches to go away sooner rather than later,
and you want to have HEAD the latest thing that new branches get
created off.
The root of the issue here, though, isn't how to use whatever tool
is used. It is an issue of release management. If you can't decide
that branch x is a stable branch, branch y is designed for new features
x, y, z and we will allow adding new features until date d1, then
stabilize the tree until it is ready, then release... you will never
solve the problem and you will always end up with staggeringly long
release cycles that no tool can fix.
Yes, doing this is hard and requires a couple of people who are willing
to keep it on track. But unless we can do this we will end up with
every branch or revision being a matter of a completely new product,
which is essentially what 1.3 to 2.0 is. I don't think release cycles
that long are condusive to retaining developers or to producing a
product that users are comfortable with upgrading from one version
to another of.
Another alternative would be to say that only changes that take no
more than a few weeks or a month to stabilize are necessary now,
so we would be fine just going along with the current HEAD and
branching off previous releases if necessary for urgent bug or security
fixes.
Re: 2.1 repository?
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Aug 30, 2002 at 09:47:28AM -0700, Justin Erenkrantz wrote:
> - As OtherBill pointed out, HEAD must remain 2.0.
Maybe HEAD should be the development trunk, while we branch off
minor (and patch) revisions for stabalization.
Like this:
HEAD
| HTTPD_2_0
| /
| /-----HTTPD_2_0_43
| /
| /-----HTTPD_2_0_42
| /
| /-----HTTPD_2_0_41
| /
|/
|
|
> - Our past strategy seems to have been that we create separate
> repositories for each minor bump.
Well, not exactly. It seems to be more based on the number of years
we'll be working on that repository. I'd rather see us only create
new repos for major revisions, then for feature revisions (aka minor
bumps, like 2.0-->2.1 for the auth stuff) then we just do a cvs branch.
> - If we ignore this and still branch for 2.1, that means we have 2.1
> under the httpd-2.0 repository. Can I say "ick" loud enough?
That's just for us, who cares?
> - Therefore, I think we should create a httpd-2.1 repository.
-0.5 Simply for the reason that I see us working on 2.1 for 4 months, then
continuing on to 2.2 for the next medium-big feature change.
> And, I'd like to seriously consider using Subversion rather than CVS.
> To me, it makes a lot of sense to switch to Subversion now rather
> than later. If we do start on a model where we 'branch early and
> often,' Subversion can handle the branching in a much better way
> than CVS can (and more scalable to boot).
A strong (non veto) -1 until subversion is 1.0 GA. Although I'd really
like to see us using Subversion, I don't think we can afford to have
any problems with the httpd project's code repositories.
> Since one of the primary matters in this 2.1 proposal is a re-org of
> certain directories, we can handle moving files without losing
> revision history. Something that is painful to do in CVS.
Yup, I agree, but that's something we're going to have to live with
just a little longer, methinks.
-aaron
Re: 2.1 repository?
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Aug 30, 2002 at 06:04:06PM +0100, Tony Finch wrote:
> The Apache project's dislike of branching seems slightly odd to me
> given that it seems to work quite effectively over long periods of
> time in the BSD projects.
+1
This is not everyone here, only a vocal minority. I am totally in favor
of using cvs branches, especially for 2.1, both for the reason that I
don't want to see an explosion of new cvs repositories, and for the fact
that _it works great for many other projects_.
-aaron
Re: 2.1 repository?
Posted by Henning Brauer <hb...@bsws.de>.
On Fri, Aug 30, 2002 at 06:04:06PM +0100, Tony Finch wrote:
> The Apache project's dislike of branching seems slightly odd to me
> given that it seems to work quite effectively over long periods of
> time in the BSD projects.
ACK.
CVS branches work out just fine for us (OpenBSD). I don't see your problems
with 'em.
--
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
Re: 2.1 repository?
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Aug 30, 2002 at 06:04:06PM +0100, Tony Finch wrote:
> On Fri, Aug 30, 2002 at 09:47:28AM -0700, Justin Erenkrantz wrote:
> >
> > And, I'd like to seriously consider using Subversion rather than CVS.
> > To me, it makes a lot of sense to switch to Subversion now rather
> > than later. If we do start on a model where we 'branch early and
> > often,' Subversion can handle the branching in a much better way
> > than CVS can (and more scalable to boot).
>
> The subversion web page says that it can't handle repeated merges, and
> still won't be able to until after 1.0. If 2.0 and 2.1 aren't going
> to diverge in an awkward fashion while parallel development continues,
> then this feature is a MUST.
Oh, give me a break. Like sticking with CVS will help? heh :-)
CVS merges are *way* worse than SVN. Yes, neither have repeated merges, but
at least SVN makes merging sane.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.1 repository?
Posted by Tony Finch <do...@dotat.at>.
On Fri, Aug 30, 2002 at 09:47:28AM -0700, Justin Erenkrantz wrote:
>
> And, I'd like to seriously consider using Subversion rather than CVS.
> To me, it makes a lot of sense to switch to Subversion now rather
> than later. If we do start on a model where we 'branch early and
> often,' Subversion can handle the branching in a much better way
> than CVS can (and more scalable to boot).
The subversion web page says that it can't handle repeated merges, and
still won't be able to until after 1.0. If 2.0 and 2.1 aren't going
to diverge in an awkward fashion while parallel development continues,
then this feature is a MUST.
The Apache project's dislike of branching seems slightly odd to me
given that it seems to work quite effectively over long periods of
time in the BSD projects.
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
LUNDY FASTNET IRISH SEA: WEST VEERING NORTH OR NORTHWEST 6 OR 7 DECREASING 4
OR 5. RAIN AT TIMES. MODERATE OR GOOD.