There is now a list to discuss this kind of things, infra-dev. I CC: it. Please drop the email to [EMAIL PROTECTED] if you answer.
El mar, 08-04-2008 a las 08:17 +0100, Danny Angus escribió: > On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala <[EMAIL PROTECTED]> wrote: > > > If I remember correctly, the policy was not to impose subversion, but to > > mandate end of life for CVS. If I remember correctly, this was due to > > security concerns, CVS requiring user accounts in the machine where the > > repository is stored while subversion does not. Also functionality. Also > > that having a lengthy transition was stressing infrastructure. I have > > been looking into mail archives but have not found a pointer yet. > > That's also my recollection. > > ... > > > I don't think centralization has ever been part of "the Apache way". > > I think the cvs-svn experience, and the wiki experience, would suggest > that we need to be mindful of the maintenance overhead of not > centralising some practical things. > I can't see any issue re: the cvs-svn experience and centralization: both environments are clearly centralized, and the migration was done by a small team, from a central repository to a central repository. The moinmoin farms as also very centralized, more aking to vhosts than to separate servers. I'm not really aware of the maintenance overhead of the wikis, but I'm betting that it is not bigger for moinmoin than for cwiki, (I think we have a number of hours donated for the maintenance of cwiki/JIRA) which in addition is proprietary. > But thats not the same as centralisation as a principle. > > And as a final point, don't take this too seriously but... the ASF and > "the Apache Way" has probably been shaped more than we would like to > admit by the workflow imposed by CVS. SVN is very similar, but > distributed source control has very different workflow which would > either conflict with or change "the way" if adopted. > The workflow you do wih most dSCM tools is literally up to you. I have prepared a refactoring for shindig ( http://github.com/sgala/apache-incubator-shindig/commits/synd-rename-2 about a 60k global patch, 38 small commits with git) using git, so that I can get familiar with advanced uses of git at the same time. I am (anybody is) free to test it in this branch that I published. What is more, everybody can look into the code with reasonable color diffs. The tool is able to rebase the patch as new commits come in, and it can merge changes inside the context of a file renamed in the first patch. What it is more, I can (anybody can) "git diff --stat -p -M synd-rename synd-rename-2" and see what changed between versions of the patch, which already allowed me to detect a merge problem that I introduced when I reordered the commits to get the patch series cleaner to look into. github can't do that, but my local gitweb can An extra goodie is that the git repo with the whole history of the project is smaller (and way faster to access) than a single subversion working copy. And this is true of every project I have tried with git-svn. You might tell me that I could have started a subversion branch to do it, and I'd answer: why is it that nobody does it in the real world? This is really where the workflow of subversion is hurting^Wshaping us. Regards Santiago > d. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
