incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject Re: Subversion vs other source control systems
Date Wed, 09 Apr 2008 06:03:02 GMT
There is now a list to discuss this kind of things, infra-dev. I CC: it.
Please drop the email to general@incubator 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 <> 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
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

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.


> d.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Santiago Gala

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message