I suppose that explains very well the reasoning for httpd layout. httpd folks believe apache-1.3 is a history, and hiding it in a branch makes it easier to make it so.
I don't think they think that at all :)
There are and there are...
>Right. At the moment we have 3 projects in perl pmc. And those are modperl1, modperl2 and modperl-docs - each needs to be on top and not hidden in a sub-branch of some other project.
I think apr is most similar in this respect:
apr/apr/ apr/apr-util/
so I guess it makes sense to have /perl/modperl /perl/modperl-docs
however, both apr and httpd have put solid and currently maintained branches
under /branches/, leaving /trunk for just the cvs HEAD equivalent.
APR is the least relevant example here, IMHO, since APR is the same thing (same origin), with different branches. modperl1 and modperl2 are not.
I don't think it hurts anything to follow this practice, just for the sake of maintaining some kind of consistency with the rest of the asf projects.
someone earlier said that it doesn't make any difference, since one just copies-n-pastes the commands. So I'd rather have an intuitive layout for modperl because it makes more sense to us (i hope), not because some other project decided that it's convenient to them.
btw, might we want to (finally) adopt mod_perl in place of modperl?
+1
may be the following is better?
/perl/mod_perl/docs
2.x
1.x
/perl/embperl/...etc?
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
