You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Danny Angus <da...@apache.org> on 2008/04/08 09:17:25 UTC
Re: Subversion vs other source control systems
On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala <sg...@apache.org> 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.
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.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Subversion vs other source control systems
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Jukka Zitting pisze:
>
> It would be cool to have a few such examples to gather more experience
> on the related workflows. Could we for example set up some git-svn
> mirrors of selected projects for people to play with? Github looks
> nice for such purposes, and I also have a spare server we could use if
> we want more control over the interaction with Apache svn.
+1 for mirroring some projects on GitHub. Personally, I'm interested in Cocoon project and has been
trying to get Git import of it for some time but without any significant result. If there is any
action on this, don't forget to send a message to this list.
> Jukka Zitting
Too bad I hadn't chance to meet you Jukka at hackathon... :-(
--
Best regards,
Grzegorz Kossakowski
Re: Subversion vs other source control systems
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Apr 9, 2008 at 9:03 AM, Santiago Gala <sg...@apache.org> wrote:
> 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.
Thanks.
> 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.
It would be cool to have a few such examples to gather more experience
on the related workflows. Could we for example set up some git-svn
mirrors of selected projects for people to play with? Github looks
nice for such purposes, and I also have a spare server we could use if
we want more control over the interaction with Apache svn.
BR,
Jukka Zitting
Re: Subversion vs other source control systems
Posted by Santiago Gala <sg...@apache.org>.
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 <sg...@apache.org> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: Subversion vs other source control systems
Posted by Santiago Gala <sg...@apache.org>.
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 <sg...@apache.org> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
--
Santiago Gala
http://memojo.com/~sgala/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org