Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote: [...]
IMO the question boils down to your expectations for using the /branch subdir. Branch management is a PITA in cvs, but it's transparent in svn. Do you expect development on modperl-1 codebase to need lots of branch work?
You never know.
Yes, you do. You can look over the long history of modperl-1 and see how often branches were needed. Since it's a stable codebase now, the future need for them should be significantly diminished. So it's reasonable to expect even fewer branches over the remaining lifespan of that codebase.
Yes, but branch belongs to a common tree. mp1 and mp2 have no common tree. And that's my main point to suggest having a separate top-level for each project.
If so, I think it makes sense for it to have it's own project subdir. If not, then why bother? (Same question applies to the modperl-docs "project", btw).
For example for a better visibility and to make it clear that modperl1 is *not* a branch of mp2 or the other way around.
Were we talking about cvs, I'd agree 100% with the visibility
argument.
What difference does it make?
But with svn, that argument rings hollow to me. Nevertheless, I'll happily adhere to your decision, if the perl PMC has sufficient participation in infrastructure@ to
manage the perl repository itself.
What needs to be managed?
Yes, I'm still worried about maintaining svn's ACL given the intertwining of the docs, test, and modperl repositories. It is difficult to protect raw uris, and there are already a few bugtraq appearances of mod_authz_svn.
In any case, since the majority seems to want the Apache way, I'm stepping aside and let you decide on how do you want the layout to be.
-- __________________________________________________________________ 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]
