They are evil in the sense that we jeopardize confusing both our users and developers with the branches. I don't believe we should rename the CVS repository (orphaning httpd-2.0). Even with your current proposal, it would silently morph all httpd-2.0 working copies to httpd (with implicit version 2.1). I don't think that's fair to our users who use CVS working copies. Our obligation to them should be that HEAD of httpd-2.0 contains, well, HEAD of httpd-2.0 not httpd 3.9.This whole 'cvs branches are evil' smacks of FUD. Certainly some operations are less than optimal. But certainly things have improved since folks experiences with branch-related bugs soured them to the concept.
I believe that the authoritative version of httpd-2.0 *must* remain in the repository called 'httpd-2.0.' I'm midly disturbed that it now contains 2.1 (mainly because there was no prior discussion about how to do the branching). 2.1 shouldn't be living in httpd-2.0 - I'd prefer that we'd back that out and start a new repository with 2.1 rather than further corrupting the 2.0 repository.
If you want to create an httpd module going forward, we could select one that doesn't have a version number in it. This would allow us to have multiple concurrent branches in one repository - there would be no contract as to what version is HEAD. Yes, we lose the ability to have contiguous history for this particular separation. If we plan wisely, that won't happen again.
However, I firmly believe that prior decisions have restricted what we can do with httpd-2.0. httpd-2.0 must live. We can't change that, nor should we be placing httpd 2.1 in there implicitly. Doing anything else is to do harm to the very people we're trying to help by imposing a versioning scheme. -- justin
