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.
In svn, branching amounts to copying one directory to another.
So if you need to make a branch of
perl/mod_perl/branches/1.x
you could copy that directory to
perl/mod_perl/branches/frobnicate-1.x-unstable/
and you're good to go. IMO it's only messy, qualitatively
speaking, if you have lots of 1.x branches mixed together with
2.x branches.
It is my contention that branches are so rare that
sharing a common branch directory will not cause confusion.
>
>> 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. 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. 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.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
