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/
