Re: 2.1 repository?
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 [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
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?
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 [EMAIL PROTECTED] 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.
Re: 2.1 repository?
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?
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
Antw: Re: 2.1 repository?
[EMAIL PROTECTED] 30.08.2002 19:20:58 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 +1 for branches And consider naming the next repository 3.x ;-) André
Re: Antw: Re: 2.1 repository?
On Fri, Aug 30, 2002 at 07:30:16PM +0200, Andre Schild wrote: +1 for branches And consider naming the next repository 3.x ;-) +1 :) -aaron
Re: 2.1 repository?
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?
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?
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?
[...] 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 [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: 2.1 repository?
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?
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/