You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2008/02/14 00:28:25 UTC
Subversion vs other source control systems
J Aaron Farr wrote:
> J Aaron Farr wrote:
>>> git could be an issue.
> > Can you explain what the issue is with Git?
> Leo already gave a decent explanation.
> Basically, it comes down to two aspects:
> 1) infrastructure support
> 2) cultural bias
Only the first one is marginally correct, IMO.
Santiago wrote:
> > 1. You have to use subversion.
> Why? Has been a vote done? where? I vote +1 for git if a vote is still open.
No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion.
No project was allowed to stay with CVS. No project will be allowed to use another source control system unless it is adopted at the ASF level. Source code is a critical, shared, public resource maintained by the Foundation, not something whose storage is managed on a project by project basis. The Infrastructure Team maintains and protects that shared resource on behalf of the Foundation.
--- Noel
---------------------------------------------------------------------
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
Re: Subversion vs other source control systems
Posted by Danny Angus <da...@apache.org>.
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 Assaf Arkin <ar...@intalio.com>.
On 2/17/08, Noel J. Bergman <no...@devtech.com> wrote:
>
> But visibility of the content and process very much IS part of "the Apache
> Way."
>
> Most of the use cases mentioned so far for git, including some where
> people are using it on top of SVN with ASF projects, run counter to ASF
> principles. It is *NOT* in our best interests and practices for people to
> work in private on bulk code, and periodically submit big changes. We want
> those changes made in public view in Subversion branches where the Community
> can see the work in progress, not when it is complete. We need to reeducate
> people who believe otherwise.
>
> That said, I am not saying that people can't use whatever SVN client(s)
> they want to use. I am saying that (a) the ASF has a uniform source control
> infrastructure, which is currently based on SVN servers, and (b) our
> practices mean that development is done in public, not done in private and
> submitted en masse as a fait accompli. These statements are independent of
> the SCM technology used by the ASF.
With all the recent interest in distributed version control, I decided to do
some research. I looked at git, hg and bzr and nothing that I read out
there convinced me that any of them offers a significant advantage over SVN.
So I decided to try one. The productivity gain was enough to win me over.
My experience is that it works much better especially for projects that
involve a distributed community of developers.
DVC do not use the same terminology as SVN. With SVN you check out code
into your local working copy, with DVC the working copy is a repository, so
checking out is effectively creating a branch. Likewise, you do not commit
from working copy to central repository, but merge from your local
repository to a more authoritive one.
So I can see how it sounds like developers on DVC are working in the dark on
big changes outside of community visibility, but only because with SVN
branches tend to encapsulate large changes. In DVC branching and merging
are done instead of checkout and commit, there's nothing anti-social about
this practice.
It's also only when you consider that every svn update and svn commit is
essentially a merge (in DVC terminology) that you realize how frequent
merges are, any why any small improvment on merge is a significant benefit.
My experience is mostly with small projects, and it does make a difference
even when working in small teams, so definitely something we should consider
for incubation projects. In fact, I think it will be easier and lower risk
to start the journey to DVC there.
Assaf
Re: Subversion vs other source control systems
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Feb 17, 2008 7:51 AM, Noel J. Bergman <no...@devtech.com> wrote:
> But visibility of the content and process very much IS part of "the Apache Way."
>
> Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. It is *NOT* in our best interests and practices for people to work in private on bulk code, and periodically submit big changes. We want those changes made in public view in Subversion branches where the Community can see the work in progress, not when it is complete. We need to reeducate people who believe otherwise.
>
> That said, I am not saying that people can't use whatever SVN client(s) they want to use. I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF.
+1. -- justin
---------------------------------------------------------------------
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 sebb <se...@gmail.com>.
[Apologies to incubator readers if you get this twice]
On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>
Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.
Switching between different repositories to work on them will generate
some overhead (if only having to think about it).
Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?
The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.
> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)
Thanks.
> > --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Subversion vs other source control systems
Posted by sebb <se...@gmail.com>.
[Apologies to incubator readers if you get this twice]
On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>
Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.
Switching between different repositories to work on them will generate
some overhead (if only having to think about it).
Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?
The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.
> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)
Thanks.
> > --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
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 sebb <se...@gmail.com>.
On 20/02/2008, Santiago Gala <sg...@apache.org> wrote:
>
> El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> > Endre Stølsvik wrote:
> >
> > > I find the decision to use one single SVN repo for the entire
> > > organization's source pretty strange. I'd believe that one repo
> > > for every TLP
> >
> > Been there, done that, have the scars.
> >
>
> Possibly using several *centralized* repositories that can't merge. May
> we know more? If not, I call FUD ask the jury to ignore the
> statement. :)
>
> > > The only downside I see is a slight bit more configuration management
> >
> > Don't be so blithe about that.
> >
>
> I actually think management would be way smaller. And, what is more
> important, distributable per repository.
>
Even if a smaller repository causes less work, there will necessarily
be some overhead per different repository - e.g. upgrades.
Switching between different repositories to work on them will generate
some overhead (if only having to think about it).
Which is easier to manage: 30 accounts with various different banks,
or one bank account with 30 times the transactions?
The work is only distributable to the extent that there are multiple
people to whom to distribute it; and certain actions would likely
still need to be co-ordinated between them.
> > > and that copying/moving a file from one repo to another would not keep history
> >
> > Unacceptable to lose it, IMO.
> >
>
> Can be done without losing history. See separate email. And I have done
> the same test with hg (basically the same) and bazaar (which required
> some command line tweaking, but doable).
>
> > And you'd be surprised how often things move around.
> >
>
> If you take a look into the basic development model in the linux kernel,
> it means moving history between repositories continuously (say from am
> to net to linus,...) Every line of code is tracked while it moves, in
> fact when Linus merges from, say, the acpi tree, the commits remain
> identical.
>
> Regards
> Santiago (I add cc: and reply-to: community)
Thanks.
> > --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> Endre Stølsvik wrote:
>
> > I find the decision to use one single SVN repo for the entire
> > organization's source pretty strange. I'd believe that one repo
> > for every TLP
>
> Been there, done that, have the scars.
>
Possibly using several *centralized* repositories that can't merge. May
we know more? If not, I call FUD ask the jury to ignore the
statement. :)
> > The only downside I see is a slight bit more configuration management
>
> Don't be so blithe about that.
>
I actually think management would be way smaller. And, what is more
important, distributable per repository.
> > and that copying/moving a file from one repo to another would not keep history
>
> Unacceptable to lose it, IMO.
>
Can be done without losing history. See separate email. And I have done
the same test with hg (basically the same) and bazaar (which required
some command line tweaking, but doable).
> And you'd be surprised how often things move around.
>
If you take a look into the basic development model in the linux kernel,
it means moving history between repositories continuously (say from am
to net to linus,...) Every line of code is tracked while it moves, in
fact when Linus merges from, say, the acpi tree, the commits remain
identical.
Regards
Santiago (I add cc: and reply-to: community)
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Subversion vs other source control systems
Posted by Santiago Gala <sg...@apache.org>.
El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió:
> Endre Stølsvik wrote:
>
> > I find the decision to use one single SVN repo for the entire
> > organization's source pretty strange. I'd believe that one repo
> > for every TLP
>
> Been there, done that, have the scars.
>
Possibly using several *centralized* repositories that can't merge. May
we know more? If not, I call FUD ask the jury to ignore the
statement. :)
> > The only downside I see is a slight bit more configuration management
>
> Don't be so blithe about that.
>
I actually think management would be way smaller. And, what is more
important, distributable per repository.
> > and that copying/moving a file from one repo to another would not keep history
>
> Unacceptable to lose it, IMO.
>
Can be done without losing history. See separate email. And I have done
the same test with hg (basically the same) and bazaar (which required
some command line tweaking, but doable).
> And you'd be surprised how often things move around.
>
If you take a look into the basic development model in the linux kernel,
it means moving history between repositories continuously (say from am
to net to linus,...) Every line of code is tracked while it moves, in
fact when Linus merges from, say, the acpi tree, the commits remain
identical.
Regards
Santiago (I add cc: and reply-to: community)
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 "Noel J. Bergman" <no...@devtech.com>.
Endre Stølsvik wrote:
> I find the decision to use one single SVN repo for the entire
> organization's source pretty strange. I'd believe that one repo
> for every TLP
Been there, done that, have the scars.
> The only downside I see is a slight bit more configuration management
Don't be so blithe about that.
> and that copying/moving a file from one repo to another would not keep history
Unacceptable to lose it, IMO.
And you'd be surprised how often things move around.
--- Noel
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El mar, 19-02-2008 a las 22:29 +0100, Endre Stølsvik escribió:
> Upayavira wrote:
> > Justin put it very well in a related thread elsewhere (permission
> > sought):
>
> [ CHOP interesting adamant view from Justin ]
> (Where is "elsewhere", btw?)
>
the discussion spread to a private list outside here. We should move
this kind of discussion to a different public list, I guess it is mostly
out of scope in general@incubator (except in the "what is the apache
way", probably) I will try to post a followup in community, again.
> What I find strange in all this is the view that ALL projects at Apache
> would have to change to OtherSCM if one project would want that..
>
I also find it strange. I guess it spreads from the fact that subversion
(or old cvs) can only preserve history easily when moving inside the
same repository.
I made an experiment, which I will publish in a blog entry, where I
"pulled" from repo2 into repo1 for two git repos. This is easy and
works, provided that there are no name collisions that are not supposed
to be merged together. If I have a hypothetical podling1 repo and
another hypothetical targetTLP1 repo, I could (say on graduation) do:
cd podling1
git-branch to_target1
git-checkout to_target1
mkdir target-tree
git mv * target-tree #"*" does not work but you get the idea...
git-commit -a -m "this is for targetTLP after graduation"
cd ../targetTLP1
git-branch merge_podling1
git-checkout merge_podling1
git-pull ../podling1 #it could be a remote repo too
...
git commit -a -m "merged podling1 in targettree"
gitk --all #to view the merged repos, it has a new "tree" in target-tree
And proceed moving code around or merging as appropriate. (Not sure how
would hg or bzr handle this use case). I don't know how this would work
in practice, there is a need to experiment this kind of things to find
corner cases and problems. But I think, as you comment in the following
paragraph, that it buys us lots of extra flexibility and scalability.
> Indeed, I find the decision to use one single SVN repo for the entire
> organization's source pretty strange. I'd believe that one repo for
> every TLP, for example, would be great (AFAIK, TLP-promotion can be
> handled too with history preserved). This would help in every single
> aspect in regard to the volume of source and activity, could use
> multiple servers etc - and incidentally using another SCM for a
> particular project wouldn't be that big a deal anymore. The only
> downside I see is a slight bit more configuration management, and that
> copying/moving a file from one repo to another would not keep history
> that well. How often does this happen, though?
Actually, if you try the above as I have done with a couple of small
repos, it keeps the whole history, including moves, committer info, etc.
Typically modern SCM (this includes subversion FWIK) don't "version
files", but rather "store graphs of commits/changesets". This means that
pulling a commit from a different repository will go pulling parent
commits up to the first common commit or, lacking it, to the root of the
history.
Regards
Santiago
> However, I'm no SVN expert, so I can easily have misunderstood
> everything.
>
> Endre.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 Upayavira <uv...@odoko.co.uk>.
On Tue, 2008-02-19 at 22:29 +0100, Endre Stølsvik wrote:
> Upayavira wrote:
> > Justin put it very well in a related thread elsewhere (permission
> > sought):
>
> [ CHOP interesting adamant view from Justin ]
> (Where is "elsewhere", btw?)
Apache has a number of "internal" lists on which members communicate
amongst themselves regarding the organisation and operation of the
Foundation.
> What I find strange in all this is the view that ALL projects at Apache
> would have to change to OtherSCM if one project would want that..
(a) we couldn't manage it otherwise, purely in terms of volunteer time
(b) we would have a disjoint set of the Foundation's core asset, which
might be acceptable temporarily, but would not as an ongoing situation.
> Indeed, I find the decision to use one single SVN repo for the entire
> organization's source pretty strange. I'd believe that one repo for
> every TLP, for example, would be great (AFAIK, TLP-promotion can be
> handled too with history preserved). This would help in every single
> aspect in regard to the volume of source and activity, could use
> multiple servers etc - and incidentally using another SCM for a
> particular project wouldn't be that big a deal anymore. The only
> downside I see is a slight bit more configuration management, and that
> copying/moving a file from one repo to another would not keep history
> that well. How often does this happen, though?
> However, I'm no SVN expert, so I can easily have misunderstood
> everything.
The thing is, that we're working with an order of magnitude more
complexity here. Setting up a wiki, you'd think that was relatively
simple task. However, once we'd set up MoinMoin wiki, we found it
couldn't handle the traffic, and entered upon a 2 month hacking bonanza
to get some kind of caching in front of it so that it would actually
stay up and respond in reasonable time. And that was only one of the
issues. We had similar issues in the early days of SVN, and we would hve
similar issues in the early days of _any_ new piece of technology that
is introduced here. That is why infra folks are resistant - they have,
by direct experience, knowledge of what it is like to change this kind
of stuff.
HTH.
Upayavira
---------------------------------------------------------------------
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 Endre Stølsvik <En...@stolsvik.com>.
Upayavira wrote:
> Justin put it very well in a related thread elsewhere (permission
> sought):
[ CHOP interesting adamant view from Justin ]
(Where is "elsewhere", btw?)
What I find strange in all this is the view that ALL projects at Apache
would have to change to OtherSCM if one project would want that..
Indeed, I find the decision to use one single SVN repo for the entire
organization's source pretty strange. I'd believe that one repo for
every TLP, for example, would be great (AFAIK, TLP-promotion can be
handled too with history preserved). This would help in every single
aspect in regard to the volume of source and activity, could use
multiple servers etc - and incidentally using another SCM for a
particular project wouldn't be that big a deal anymore. The only
downside I see is a slight bit more configuration management, and that
copying/moving a file from one repo to another would not keep history
that well. How often does this happen, though?
However, I'm no SVN expert, so I can easily have misunderstood
everything.
Endre.
---------------------------------------------------------------------
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 Upayavira <uv...@odoko.co.uk>.
On Tue, 2008-02-19 at 11:51 +0100, Endre Stølsvik wrote:
> Justin Erenkrantz wrote:
> > On Feb 18, 2008 10:48 AM, Santiago Gala <sg...@apache.org> wrote:
> >> outright FUD? Sorry but I don't think there is Fear, Uncertainty or
> >> Doubt in this thread. There are several testimonies of good experiences
> >
> > I feel there has been lots of FUD and if you don't realize that, then
> > I recommend taking a step back.
>
> Please define FUD for us, will you? Because I haven't seen one single
> iota of FUD on this thread - it has stayed strangely on topic, with good
> arguments from both sides, and not once has the discussion gone into
> "SCM XYZ often ruins the code base by introducing strange bit
> errors"-style "half-lies" which is what I associate with FUD.
> A/k/a "The Microsoft Tactics" in regards to Linux.
I'm not going to argue whether there specifically is "FUD", but there is
_serious_ underestimation of what it takes to roll out something as
crucial as source control within an organisation the size of Apache, and
with a repository the size of Apache.
Justin put it very well in a related thread elsewhere (permission
sought):
- o -
"The JAMES PMC knows that if they want to run on apache.org, they have
to handle *all* of the list traffic - not just their list. So far,
they've not made a request to do so. In some cases, it doesn't have
to be total conversion - for example, in infra, we're very hopeful
that we can run Harmony in some cases where we run Java - but Harmony
is not yet capable of running Confluence, so we can't switch over.
But, for a SCM, it *must* be on a path towards total conversion -
nothing less is acceptable, IMO. We will *not* have a fractured
repository system like FreeBSD or Perl.
"If a PMC asked to run their own individual SCMs, they'd simply be
turned down. If we switch our SCM to anything else, *everything* must
switch over. IMO, at this point, we simply do not have anything other
than a few people who may have used git a few times - but we certainly
don't have any folks who appear willing to step up and realistically
and soberly consider what it means to change *everything* over.
Compare and contrast our experience with Subversion and let that
*truly* sink in if you're even a bit flippant about what it means to
switch. Converting from CVS to Subversion took *years* to accomplish
and it took a *lot* of us getting deep inside the SVN community and
codebase to make sure it'd work for us. Converting to something else
would take a realistically long time as well with a concomitant set of
expectations that folks will actively improve the tool to meet our
requirements. So far, all I'm seeing is a few people saying, "It'd be
nice if someone else converts the ASF to git." Those comments are
completely irrational and misguided as to how we work. If you're so
bent on getting us on another SCM, then join the infrastructure list
and start proving that it's better than SVN.
"FWIW, git and mercurial (mercurial is *far* better than git in my
experience; it's not even close, to be honest) do not scale well to
*really* *really* large repositories. If you look at KDE's trial
migration to git (which Joe and myself and others are watching
closely), they are separating every KDE deliverable into a separate
git repository. (That is, every KDE library gets its own git
repository - so kdelibs and kdedesktop are treated separately.) KDE
is explicitly willing to lose history when they move things between
repositories. I'm frankly not sure that we'd find that acceptable.
Mercurial has sketched out a concept of 'forests' (of related
repositories), but again they're not thinking in terms of anything
other than an individual codebase - certainly not 25GB+ and across 60+
TLPs. And, AFAICT, the concept of 'forests' is sketchy and not a part
of the core Mercurial codebase (think svn:externals and you've got an
idea how they implemented 'forests'). Again, with those SCMs, they're
perfectly willing to sacrifice history as it moves across those small
repositories as cross-project history is not something they care to
support."
- o -
Now, that, in my impression, puts the situation very well. If we were to
switch to git, or anything else, there would be huge issues involved,
and would be probably years of work to manage the transition. If that is
what is generally wanted, then we need volunteers who will put
themselves behind the task. No small feat. I have seen such changes
happen at Apache - they can, but the issues involved from an
infrastructure point of view are invariably an order of magnitude (if
not two orders) harder than those you see on one's own, typically
smaller, installations.
Regards, Upayavira
---------------------------------------------------------------------
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 Endre Stølsvik <En...@stolsvik.com>.
Justin Erenkrantz wrote:
> On Feb 18, 2008 10:48 AM, Santiago Gala <sg...@apache.org> wrote:
>> outright FUD? Sorry but I don't think there is Fear, Uncertainty or
>> Doubt in this thread. There are several testimonies of good experiences
>
> I feel there has been lots of FUD and if you don't realize that, then
> I recommend taking a step back.
Please define FUD for us, will you? Because I haven't seen one single
iota of FUD on this thread - it has stayed strangely on topic, with good
arguments from both sides, and not once has the discussion gone into
"SCM XYZ often ruins the code base by introducing strange bit
errors"-style "half-lies" which is what I associate with FUD.
A/k/a "The Microsoft Tactics" in regards to Linux.
Endre.
---------------------------------------------------------------------
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 Justin Erenkrantz <ju...@erenkrantz.com>.
On Feb 18, 2008 10:48 AM, Santiago Gala <sg...@apache.org> wrote:
> outright FUD? Sorry but I don't think there is Fear, Uncertainty or
> Doubt in this thread. There are several testimonies of good experiences
I feel there has been lots of FUD and if you don't realize that, then
I recommend taking a step back.
> Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a
> different 1.4.3 Mandriva rpm). I guess they don't ship "contrib" stuff.
...
> Well, I tried svk, git, mercurial and bzr. I am even using darcs because
> of some openID code I track. I prefer git, even when forced to use
> git-svn, to svk. Still, I will try to look into svnmerge.py, I found it
> here http://www.orcaware.com/svn/wiki/Svnmerge.py
That's ancient. svnmerge.py lives in the subversion codebase:
http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/
In Ubuntu, it's part of subversion-tools package. I don't profess to
know where your OS ships it, but Ubuntu has it available for one. I
don't know how current that svnmerge.py is, but it's there...
> Linus Torvalds discusses extensively work flow processes in
> http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is
> mostly right in the fact that distribution is the way to go, and not
> just because of disconnected operation. In one of the projects I track
> and patch, I don't commit myself, but I have contributed a number of
> components and patches and I keep ongoing patches. I would never be able
> to use svnmerge.py without the ability to create branches or commit.
Linus has his own ideas how a projects should run which are not, uh,
quite compatible with how Apache projects operate. In other words,
there is one VIP who cuts all releases or holds onto the 'official'
repository. Distributed SCMs are often ideal for ego-centric open
source. -- justin
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El dom, 17-02-2008 a las 17:24 -0800, Justin Erenkrantz escribió:
> On Feb 17, 2008 3:34 PM, Santiago Gala <sg...@apache.org> wrote:
> > Also: you keep a long term branch for doing some refactoring, and you
> > fix small bugs both in HEAD and in a release branch, merging and
> > backporting/forwardporting as you go. Again, something like git makes
> > the work simpler and keeps the disk requirements under control.
>
> In an attempt to stop some of the outright FUD in this thread before
> it goes on to yet another mailing list...
outright FUD? Sorry but I don't think there is Fear, Uncertainty or
Doubt in this thread. There are several testimonies of good experiences
with git, and the only "downplay" of subversion has been the problems
with merging, which I think are real. I would only call FUD if there had
been mentions, say, to subversion corrupting repositories or similar,
and I think those times are far in the past.
>
> I've found that svnmerge.py (distributed with SVN) handles pretty much
> all of the branch/merge tracking capabilities that I personally care
> about. (The drawback is that it isn't as efficient as we'd like, but
Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a
different 1.4.3 Mandriva rpm). I guess they don't ship "contrib" stuff.
Linus Torvalds discusses extensively work flow processes in
http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is
mostly right in the fact that distribution is the way to go, and not
just because of disconnected operation. In one of the projects I track
and patch, I don't commit myself, but I have contributed a number of
components and patches and I keep ongoing patches. I would never be able
to use svnmerge.py without the ability to create branches or commit.
> it's good enough. The 1.5 stuff is *way* faster.) From your
> statements, you probably haven't bothered to try svnmerge.py (usable
> with 1.4.x) or any of the new reintegrate merge stuff in 1.5. It
> makes it pretty brain-dead simple to handle most branch-oriented
> merging cases. There are a few pathological cases that don't work
> well, but that's 'reflective' merging which isn't the 95% use case -
> so it got punted to post-1.5. (svnmerge.py is probably the 80% use
> case, with 1.5 merge tracking being 90%, and reflective merging being
> that last gap...)
> FWIW, for svn.apache.org, I have a feeling we'll probably be a tad
> aggressive on rolling out 1.5.
> (Besides merge tracking, there are a number of excellent features in
> 1.5: changelist support, interactive conflict resolution, read/write
> transparent proxies, integrated 'diff -x -p' support, substantial
> svnsync speed improvements, partial svnsync ability, etc.) Note that
> nothing is stopping you from using svnmerge.py today. If folks are
> going to complain about switching to another SCM because of a lack of
> decent merging, then they owe it to themselves to check out what
> Subversion can actually do rather than what they think it can do...
> -- justin
Well, I tried svk, git, mercurial and bzr. I am even using darcs because
of some openID code I track. I prefer git, even when forced to use
git-svn, to svk. Still, I will try to look into svnmerge.py, I found it
here http://www.orcaware.com/svn/wiki/Svnmerge.py
Regards
Santiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 Justin Erenkrantz <ju...@erenkrantz.com>.
On Feb 17, 2008 3:34 PM, Santiago Gala <sg...@apache.org> wrote:
> Also: you keep a long term branch for doing some refactoring, and you
> fix small bugs both in HEAD and in a release branch, merging and
> backporting/forwardporting as you go. Again, something like git makes
> the work simpler and keeps the disk requirements under control.
In an attempt to stop some of the outright FUD in this thread before
it goes on to yet another mailing list...
I've found that svnmerge.py (distributed with SVN) handles pretty much
all of the branch/merge tracking capabilities that I personally care
about. (The drawback is that it isn't as efficient as we'd like, but
it's good enough. The 1.5 stuff is *way* faster.) From your
statements, you probably haven't bothered to try svnmerge.py (usable
with 1.4.x) or any of the new reintegrate merge stuff in 1.5. It
makes it pretty brain-dead simple to handle most branch-oriented
merging cases. There are a few pathological cases that don't work
well, but that's 'reflective' merging which isn't the 95% use case -
so it got punted to post-1.5. (svnmerge.py is probably the 80% use
case, with 1.5 merge tracking being 90%, and reflective merging being
that last gap...)
FWIW, for svn.apache.org, I have a feeling we'll probably be a tad
aggressive on rolling out 1.5.
(Besides merge tracking, there are a number of excellent features in
1.5: changelist support, interactive conflict resolution, read/write
transparent proxies, integrated 'diff -x -p' support, substantial
svnsync speed improvements, partial svnsync ability, etc.) Note that
nothing is stopping you from using svnmerge.py today. If folks are
going to complain about switching to another SCM because of a lack of
decent merging, then they owe it to themselves to check out what
Subversion can actually do rather than what they think it can do...
-- justin
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El dom, 17-02-2008 a las 19:12 +0100, Leo Simons escribió:
> On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote:
> > Most of the use cases mentioned so far for git, including some
> > where people are using it on top of SVN with ASF projects, run
> > counter to ASF principles.
>
> Let me fix that:
>
> Use case: work on apache project while on plane
> -----------------------------------------------
> * export list of jiras of your favorite ASF project into spreadsheet
> * sync project repo to your laptop
> * get on a plane for 14 hours
> * slave away at the bug list, fixing a bunch
> * create one patch per bug, with a good commit message, referring
> to the bug report, and commit locally
> * get off the plane
> * get online
> * sync project repo to your laptop
> * resolve any conflicts
> * for each bug report
> * submit and commit the fix
> * close the bug report
>
> This is easy to do with git. It's a small nightmare with SVN,
> especially if your project is a million lines of code.
>
A big +1 on this use case. Have you tried this one?
Also: you keep a long term branch for doing some refactoring, and you
fix small bugs both in HEAD and in a release branch, merging and
backporting/forwardporting as you go. Again, something like git makes
the work simpler and keeps the disk requirements under control.
> (you could substitute "while on plane" with "even if network craps
> out at hackathon" or with "at a customer site with big firewall")
>
> > I am saying that (a) the ASF has a uniform source control
> > infrastructure, which is currently based on SVN servers, and (b)
> > our practices mean that development is done in public, not done in
> > private and submitted en masse as a fait accompli. These
> > statements are independent of the SCM technology used by the ASF.
>
> Exactly!
>
Agreed too.
>
> cheers,
>
>
> - Leo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 Justin Erenkrantz <ju...@erenkrantz.com>.
On Feb 18, 2008 1:01 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> the last time i tried SVK, changes would be needed to SVK before it
> could work with a repository as big as apache
FWIW, the partial svnsync changes that SVK would need are present in
1.5. I don't know if the SVK community has picked up on that yet, but
SVN 1.5 clients/servers will support it. -- justin
---------------------------------------------------------------------
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 Robert Burrell Donkin <ro...@gmail.com>.
On Feb 18, 2008 2:08 PM, Daniel S. Haischt
<da...@googlemail.com> wrote:
> Seems like people weren't interested in SVK but solely in Git. Otherwise
> this thread would have come to an end pretty soon without the need of
> all the FUD cause I suggested/asked to use SVK some days ago already.
the last time i tried SVK, changes would be needed to SVK before it
could work with a repository as big as apache
- robert
---------------------------------------------------------------------
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 "Daniel S. Haischt" <da...@googlemail.com>.
Seems like people weren't interested in SVK but solely in Git. Otherwise
this thread would have come to an end pretty soon without the need of
all the FUD cause I suggested/asked to use SVK some days ago already.
It doesn't figure why infrastructure stuff needs to be discussed in
such a intensity on the incubator list anyway.
Just my two cents ...
Noah Slater wrote:
>
> Sorry for butting in this discussion, but I would like to point out that this is
> only a problem for the standard Subversion client. As an SVK user (another
> Subversion client) I regularly make use of off-line commits, local mirroring and
> smart merges.
>
---------------------------------------------------------------------
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 Noah Slater <ns...@bytesexual.org>.
> Use case: work on apache project while on plane
> -----------------------------------------------
> * export list of jiras of your favorite ASF project into spreadsheet
> * sync project repo to your laptop
> * get on a plane for 14 hours
> * slave away at the bug list, fixing a bunch
> * create one patch per bug, with a good commit message, referring
> to the bug report, and commit locally
> * get off the plane
> * get online
> * sync project repo to your laptop
> * resolve any conflicts
> * for each bug report
> * submit and commit the fix
> * close the bug report
>
> This is easy to do with git. It's a small nightmare with SVN, especially
> if your project is a million lines of code.
Sorry for butting in this discussion, but I would like to point out that this is
only a problem for the standard Subversion client. As an SVK user (another
Subversion client) I regularly make use of off-line commits, local mirroring and
smart merges.
--
Noah Slater <http://bytesexual.org/>
---------------------------------------------------------------------
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 "Noel J. Bergman" <no...@devtech.com>.
Leo Simons wrote:
> Noel J. Bergman wrote:
> > Most of the use cases mentioned so far for git, including some
> > where people are using it on top of SVN with ASF projects, run
> > counter to ASF principles.
> Let me fix that [...]
Fine, but again, the Incubator isn't where ASF Infrastructure decisions are
made. You know where to go to discuss improvement and/or migration of ASF
source management.
> > I am saying that (a) the ASF has a uniform source control
> > infrastructure, which is currently based on SVN servers, and (b)
> > our practices mean that development is done in public, not done in
> > private and submitted en masse as a fait accompli. These
> > statements are independent of the SCM technology used by the ASF.
> Exactly!
Good, because this is the only thing from this discussion that's in scope
for the Incubator.
--- Noel
---------------------------------------------------------------------
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 Leo Simons <ma...@leosimons.com>.
On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote:
> Most of the use cases mentioned so far for git, including some
> where people are using it on top of SVN with ASF projects, run
> counter to ASF principles.
Let me fix that:
Use case: work on apache project while on plane
-----------------------------------------------
* export list of jiras of your favorite ASF project into spreadsheet
* sync project repo to your laptop
* get on a plane for 14 hours
* slave away at the bug list, fixing a bunch
* create one patch per bug, with a good commit message, referring
to the bug report, and commit locally
* get off the plane
* get online
* sync project repo to your laptop
* resolve any conflicts
* for each bug report
* submit and commit the fix
* close the bug report
This is easy to do with git. It's a small nightmare with SVN,
especially if your project is a million lines of code.
(you could substitute "while on plane" with "even if network craps
out at hackathon" or with "at a customer site with big firewall")
> I am saying that (a) the ASF has a uniform source control
> infrastructure, which is currently based on SVN servers, and (b)
> our practices mean that development is done in public, not done in
> private and submitted en masse as a fait accompli. These
> statements are independent of the SCM technology used by the ASF.
Exactly!
cheers,
- Leo
---------------------------------------------------------------------
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 "Noel J. Bergman" <no...@devtech.com>.
Santiago Gala wrote:
> Noel J. Bergman escribió:
> > No project was allowed to stay with CVS. No project will be allowed to
> > use another source control system unless it is adopted at the ASF
> > level. Source code is a critical, shared, public resource maintained
> > by the Foundation, not something whose storage is managed on a project
> > by project basis. The Infrastructure Team maintains and protects that
> > shared resource on behalf of the Foundation.
> If I remember correctly, the policy was not to impose subversion, but to
> mandate end of life for CVS.
You remember incorrectly. The mandate was to migrate from Infrastructure-managed CVS to Infrastructure-managed Subversion, not from CVS to the SCM of your choice.
> 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.
There were a variety of reasons, including the above, but none of that addresses your apparent belief that the ASF should support ad hoc and arbitrary selections of critical infrastructure by individual projects.
> - you are no longer considering the Foundation as an umbrella for the
> projects, but as an entity with a life that, I see from your reaction,
> needs to protect itself from the (some?) projects
That is an extreme interpretation. I could as easily say that you are in favor of each project being able to maintain its own critical infrastructure on any servers anywhere with arbitrary security and community practices. I don't believe that is your actual view, but I could take your words to say so.
> - The infrastructure team is a Police body ("to serve and protect")
Saying that ensuring availability and safety (from loss and/or tampering) is one of the goals we have with respect to our data is hardly the same as your claim.
> Information can be copied and still stays the same, trying to restrict
> it to a server is really futile and wasting.
I have no idea what you're talking about here.
> I don't think centralization has ever been part of "the Apache way".
But visibility of the content and process very much IS part of "the Apache Way."
Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. It is *NOT* in our best interests and practices for people to work in private on bulk code, and periodically submit big changes. We want those changes made in public view in Subversion branches where the Community can see the work in progress, not when it is complete. We need to reeducate people who believe otherwise.
That said, I am not saying that people can't use whatever SVN client(s) they want to use. I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF.
--- Noel
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El mié, 13-02-2008 a las 18:28 -0500, Noel J. Bergman escribió:
> J Aaron Farr wrote:
> > J Aaron Farr wrote:
> >>> git could be an issue.
> > > Can you explain what the issue is with Git?
> > Leo already gave a decent explanation.
> > Basically, it comes down to two aspects:
> > 1) infrastructure support
> > 2) cultural bias
>
> Only the first one is marginally correct, IMO.
>
> Santiago wrote:
> > > 1. You have to use subversion.
> > Why? Has been a vote done? where? I vote +1 for git if a vote is still open.
>
> No, there was no vote and is not vote, nor is there any choice.
> Subversion is one of the few things that the Board has mandated,
> imposed on all projects. Period. Pretty much end of discussion.
>
> No project was allowed to stay with CVS. No project will be allowed to
> use another source control system unless it is adopted at the ASF
> level. Source code is a critical, shared, public resource maintained
> by the Foundation, not something whose storage is managed on a project
> by project basis. The Infrastructure Team maintains and protects that
> shared resource on behalf of the Foundation.
>
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.
Funny enough, all people using distributed SCM quoted ease and
simplification of administration as one of the core advantages, be it
git, bazaar, mercurial or darcs.
If I read correctly your last two sentences, I see that
- you are no longer considering the Foundation as an umbrella for the
projects, but as an entity with a life that, I see from your reaction,
needs to protect itself from the (some?) projects
- The infrastructure team is a Police body ("to serve and protect")
Information can be copied and still stays the same, trying to restrict
it to a server is really futile and wasting. The only thing that
actually would need a "custody" would be a PGP-signed text document with
SHA1 of the release source and date. And I don't think it would be
signed by the infrastructure team, but by the three +1 voters of the
release in the PMC. And this "custody" can easily be achieved by
publishing in a multiply archived email list.
I don't think centralization has ever been part of "the Apache way".
Regards
Santiago
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El jue, 14-02-2008 a las 14:32 +0100, Erik Abele escribió:
> On 14.02.2008, at 14:14, Santiago Gala wrote:
>
> > ...
> > The typical workflow in distributed scm is that authoritative
> > repositories pull (as requested and after review) from non-official
> > ones, so typically security is easier: no longer lots of people with
> > write access, but only a handful, taking changesets from the rest
> > of the
> > community.
>
> Aye, and this is also the reason why it potentially conflicts with
> the meritocratic model of the ASF; furthermore there are also legal
> hurdles to cross etc.
>
I can't see where are the legal or meritocratic problems, really.
Specially the legal ones. A changeset is a changeset, whereas it is
stored in subversion, several git repos or a patch in jira.
I can agree that some experimentation is needed to refine the work flows
and see how it works with our models, but denial will not help getting
work done in this area.
> In the end I think it's simply too early to discuss all this - let's
> wait until some project comes up with a well-prepared and clearly
> defined proposal to change their SCM. IMHO this is certainly not a
> task for the Incubator or a podling...
>
Neither is a task for the incubator PMC to freeze the new teams, and cut
off the fresh air from the ASF. Raising an expectation that you *can*
defy the powers-that-be here was my main aim in this whole thread. :)
> Cheers,
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El jue, 14-02-2008 a las 14:45 +0100, Jochen Wiedmann escribió:
> On Thu, Feb 14, 2008 at 2:32 PM, Erik Abele <er...@codefaktor.de> wrote:
>
> > Aye, and this is also the reason why it potentially conflicts with
> > the meritocratic model of the ASF; furthermore there are also legal
> > hurdles to cross etc.
> >
> > In the end I think it's simply too early to discuss all this - let's
> > wait until some project comes up with a well-prepared and clearly
> > defined proposal to change their SCM. IMHO this is certainly not a
> > task for the Incubator or a podling...
>
> Agreed. It's better to wait. Also note, that:
>
> - For obvious reasons, git and other distributed VC systems are more suited
> for larger projects with a real lot of contributors. Even in the case of the
> top level projects, there aren't too many that qualify for that.
I don't see the "obvious reasons", of course excepting much better
performance of git. I mostly use bazaar for small projects, for instance
put /etc of a group of servers under version control, and have the
ability to commit remote configuration changes and then push to/pull
from the remote server. I think the smaller management overhead of
bazaar or git makes it easier than having to set up and protect svn
server and repositories.
> - Even now, it is possible to work with git, if you want to: See
>
> http://mail-archives.apache.org/mod_mbox/maven-dev/200709.mbox/%3C1B829E89-25ED-446D-B31D-A881692F949B@maven.org%3E
>
> I do not know how far Jason van Zyl's attempts have grown or not,
He is making basically the same points I tried to make, and with a lot
of enthusiasm too... I hope this will help convincing people to try any
of the tools.
> but the point
> is that his intentions have been to gather experience. Anyone else is free to
> do the same.
Well, I answered to Noel's:
> No, there was no vote and is not vote, nor is there any choice.
> Subversion is one of the few things that the Board has mandated,
> imposed on all projects. Period. Pretty much end of discussion.
because he was clearly implying that no, nobody is free to do the same.
Now at least I see that I'm not alone here. And hopefully people in
podlings will see that we are a bit less uniform and bureaucratic than
they were fearing. :)
Regards
Santiago
>
> Jochen
>
>
---------------------------------------------------------------------
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 Jochen Wiedmann <jo...@gmail.com>.
On Thu, Feb 14, 2008 at 2:32 PM, Erik Abele <er...@codefaktor.de> wrote:
> Aye, and this is also the reason why it potentially conflicts with
> the meritocratic model of the ASF; furthermore there are also legal
> hurdles to cross etc.
>
> In the end I think it's simply too early to discuss all this - let's
> wait until some project comes up with a well-prepared and clearly
> defined proposal to change their SCM. IMHO this is certainly not a
> task for the Incubator or a podling...
Agreed. It's better to wait. Also note, that:
- For obvious reasons, git and other distributed VC systems are more suited
for larger projects with a real lot of contributors. Even in the case of the
top level projects, there aren't too many that qualify for that.
- Even now, it is possible to work with git, if you want to: See
http://mail-archives.apache.org/mod_mbox/maven-dev/200709.mbox/%3C1B829E89-25ED-446D-B31D-A881692F949B@maven.org%3E
I do not know how far Jason van Zyl's attempts have grown or not,
but the point
is that his intentions have been to gather experience. Anyone else is free to
do the same.
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
---------------------------------------------------------------------
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 Erik Abele <er...@codefaktor.de>.
On 14.02.2008, at 14:14, Santiago Gala wrote:
> ...
> The typical workflow in distributed scm is that authoritative
> repositories pull (as requested and after review) from non-official
> ones, so typically security is easier: no longer lots of people with
> write access, but only a handful, taking changesets from the rest
> of the
> community.
Aye, and this is also the reason why it potentially conflicts with
the meritocratic model of the ASF; furthermore there are also legal
hurdles to cross etc.
In the end I think it's simply too early to discuss all this - let's
wait until some project comes up with a well-prepared and clearly
defined proposal to change their SCM. IMHO this is certainly not a
task for the Incubator or a podling...
Cheers,
Erik
---------------------------------------------------------------------
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 "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Santiago Gala wrote:
> I'd say that if a project wants to have a distributed scm and makes a
> reasonable case of the reasons, they would ask for it to infrastructure.
> If infrastructure denies it and the project does not accept the
> reasoning or how it is exposed, we have a conflict. If there is a
> conflict the Board *has* to consider the issue. I'm not sure on how it
> is worded in the bylines.
Well, yes, board is the appeal of last resort. But just like the board
rarely touches the third rail of making development decisions for a project,
they rarely make architectural decisions overriding infrastructure.
The right way is for infra to determine they won't do it unless ___ happens,
and appeal to the board to make ___ happen on behalf of the requester.
> While we typically value consensus a lot, we typically don't take
> bureaucratic answers as absolutes. Or at least that is how I remember
> the ASF used to be. :P
You can't have a less absolute bureaucratic result than bringing an issue
to the board ;-)
> The typical workflow in distributed scm is that authoritative
> repositories pull (as requested and after review) from non-official
> ones, so typically security is easier: no longer lots of people with
> write access, but only a handful, taking changesets from the rest of the
> community.
But there's a deep question of if this goes against the principals of the
meritocracy of peers that has worked so well for the ASF. We don't and
wouldn't entertain such roles as code wrangler, project lead, etc. It's
just not our ethos/social schema.
Bill
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El jue, 14-02-2008 a las 10:52 +0000, William A. Rowe, Jr. escribió:
> Janne Jalkanen wrote:
> >> No, there was no vote and is not vote, nor is there any choice.
> >> Subversion is one of the few things that the Board has mandated,
> >> imposed on all projects. Period. Pretty much end of discussion.
> >
> > I would assume though that if there is enough interest among the
> > community, the subject of supporting something like Git could be opened
> > up with the Board, yes?
>
> It's up to the infrastructure team to decide, the board is generally
> hands-off when it comes to their decisions for the foundation.
>
> So it needs to be brought up to them.
>
I'd say that if a project wants to have a distributed scm and makes a
reasonable case of the reasons, they would ask for it to infrastructure.
If infrastructure denies it and the project does not accept the
reasoning or how it is exposed, we have a conflict. If there is a
conflict the Board *has* to consider the issue. I'm not sure on how it
is worded in the bylines.
While we typically value consensus a lot, we typically don't take
bureaucratic answers as absolutes. Or at least that is how I remember
the ASF used to be. :P
Also, while all users have http://people.apache.org/~userid/ , a
git/bazaar/mercurial/darcs repo is only one scp away. I have set up cvs,
subversion, git and bazaar, and the last two were vastly easier to set
up and maintain. As I said, specially if ssh/sftp is there.
The typical workflow in distributed scm is that authoritative
repositories pull (as requested and after review) from non-official
ones, so typically security is easier: no longer lots of people with
write access, but only a handful, taking changesets from the rest of the
community.
Regards
Santiago
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Janne Jalkanen wrote:
>> No, there was no vote and is not vote, nor is there any choice.
>> Subversion is one of the few things that the Board has mandated,
>> imposed on all projects. Period. Pretty much end of discussion.
>
> I would assume though that if there is enough interest among the
> community, the subject of supporting something like Git could be opened
> up with the Board, yes?
It's up to the infrastructure team to decide, the board is generally
hands-off when it comes to their decisions for the foundation.
So it needs to be brought up to them.
---------------------------------------------------------------------
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 Janne Jalkanen <Ja...@ecyrd.com>.
> No, there was no vote and is not vote, nor is there any choice.
> Subversion is one of the few things that the Board has mandated,
> imposed on all projects. Period. Pretty much end of discussion.
I would assume though that if there is enough interest among the
community, the subject of supporting something like Git could be
opened up with the Board, yes?
/Janne, who does not really know how this bit of ASF works...
---------------------------------------------------------------------
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 "Daniel S. Haischt" <da...@googlemail.com>.
would SVK be an option? This would allow to re-use the already existing SVN
infrastracture.
No need for changes to the ASF infrastructure...
On Thu, Feb 14, 2008 at 1:55 PM, Santiago Gala <sg...@apache.org> wrote:
>
> El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribió:
>
> > On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:
> >
> > > Noel J. Bergman wrote:
> > >> J Aaron Farr wrote:
> > >>> J Aaron Farr wrote:
> > >>>>> git could be an issue.
> > >>>> Can you explain what the issue is with Git?
> > >>> Leo already gave a decent explanation.
> > >>> Basically, it comes down to two aspects:
> > >>> 1) infrastructure support
> > >>> 2) cultural bias
> > >> Only the first one is marginally correct, IMO.
> > >> Santiago wrote:
> > >>>> 1. You have to use subversion.
> > >
> > >
> > > Sorry, I've missed the thread that led to this, so sorry if I'm
> > > repeating others.
> > >
> > > I understand that GiT can be used locally as a layer on top of SVN.
> > > I believe this gives you most of the perceived benefits of GiT
> > > locally without the need for a project itself to switch to GiT.
> >
> > I am a bit lost here as well -- what does GiT add to the processes/
> > workflows common in the ASF ?
> >
>
> It adds:
> - ability to have offline commits
> - much faster repository diff, status, etc. that works offline
> - (git-specific) ability to reorder and aggregate several private
> commits to deliver a consistent patch. This can only be simulated with
> other tools
> - ability to publish (push/pull) branches easily for tests without
> compromising the main line. Subversion branches, while easy to create,
> are awful to maintain and rarely used.
> - clean and remembered merges: patches with clear attribution that can
> be merged multiple times which, again, makes easy maintenance of several
> branches running in parallel.Backports, etc.
>
>
>
> > One of the great things about GiT is that you can can have lots of
> > parallel and non-linear merges (every developer their own branch; lots
> > of people merging the same patch into different sequences) -- and as
> > such I can see it being perfectly tuned for, say, Linux.
> >
>
> Precisely the fact that patches are accepted in just 'one' or 'a few'
> points make invaluable having good maintenance of in-progress work.
>
>
> > However in the ASF most groups work roughly along fairly linear lines;
> > with 'one' or just a 'few' points at which a patch is accepted - and
> > essentially few, or just one, merge point (or a single line of merge
> > points when backported). Rarely do we merge multiple 'HEAD's.
> >
>
> Not in my experience, it is common to have in-progress work in parallel
> with bugfixes, etc. subversion is awful for tracking multiple branches
> in parallel, to the point that I have been using quilt for patch
> management of top of subversion. This is clearly a kludge that reveals
> the deficiencies of the workflow.
>
> You see? "rarely do we merge multiple HEADs" is seen from the point of
> view of the repository. If you have 10 developers working on patches,
> you have 10 people merging continuously their branch with the "official"
> one. Rarely applies only to the subversion repo.
>
>
> > And I'd almost argue that SVN is a useful framework which helps us
> > stay on the paved roads - where a single head progresses with group
> > consensus and generally agreed merit.
> >
>
> I've seen plenty of times where having in-progress patches were
> consistently conflicted by commits, which multiplied the work implied in
> keeping them to the point of dropping them (personal). This is trivially
> easy to do with bazaar or git, and I'm quite sure that darcs or
> mercurial will offer the same comfort level.
>
> At least for my development style, distributed SCM offers one order of
> magnitude more comfortable environment than centralized SCM.
>
> As for your concrete sentence, I'd say that if you need a technical tool
> as a framework to impose a work flow, then the work flow is possibly
> broken. If the work flow is sound, having a tool that eases the work
> won't break it.
>
> Regards
> Santiago (who was working to deliver this and more info on technical
> merits in the community@apache.org thread)
>
>
>
> > Thanks,
> >
> > Dw
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribió:
> On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:
>
> > Noel J. Bergman wrote:
> >> J Aaron Farr wrote:
> >>> J Aaron Farr wrote:
> >>>>> git could be an issue.
> >>>> Can you explain what the issue is with Git?
> >>> Leo already gave a decent explanation.
> >>> Basically, it comes down to two aspects:
> >>> 1) infrastructure support
> >>> 2) cultural bias
> >> Only the first one is marginally correct, IMO.
> >> Santiago wrote:
> >>>> 1. You have to use subversion.
> >
> >
> > Sorry, I've missed the thread that led to this, so sorry if I'm
> > repeating others.
> >
> > I understand that GiT can be used locally as a layer on top of SVN.
> > I believe this gives you most of the perceived benefits of GiT
> > locally without the need for a project itself to switch to GiT.
>
> I am a bit lost here as well -- what does GiT add to the processes/
> workflows common in the ASF ?
>
It adds:
- ability to have offline commits
- much faster repository diff, status, etc. that works offline
- (git-specific) ability to reorder and aggregate several private
commits to deliver a consistent patch. This can only be simulated with
other tools
- ability to publish (push/pull) branches easily for tests without
compromising the main line. Subversion branches, while easy to create,
are awful to maintain and rarely used.
- clean and remembered merges: patches with clear attribution that can
be merged multiple times which, again, makes easy maintenance of several
branches running in parallel.Backports, etc.
> One of the great things about GiT is that you can can have lots of
> parallel and non-linear merges (every developer their own branch; lots
> of people merging the same patch into different sequences) -- and as
> such I can see it being perfectly tuned for, say, Linux.
>
Precisely the fact that patches are accepted in just 'one' or 'a few'
points make invaluable having good maintenance of in-progress work.
> However in the ASF most groups work roughly along fairly linear lines;
> with 'one' or just a 'few' points at which a patch is accepted - and
> essentially few, or just one, merge point (or a single line of merge
> points when backported). Rarely do we merge multiple 'HEAD's.
>
Not in my experience, it is common to have in-progress work in parallel
with bugfixes, etc. subversion is awful for tracking multiple branches
in parallel, to the point that I have been using quilt for patch
management of top of subversion. This is clearly a kludge that reveals
the deficiencies of the workflow.
You see? "rarely do we merge multiple HEADs" is seen from the point of
view of the repository. If you have 10 developers working on patches,
you have 10 people merging continuously their branch with the "official"
one. Rarely applies only to the subversion repo.
> And I'd almost argue that SVN is a useful framework which helps us
> stay on the paved roads - where a single head progresses with group
> consensus and generally agreed merit.
>
I've seen plenty of times where having in-progress patches were
consistently conflicted by commits, which multiplied the work implied in
keeping them to the point of dropping them (personal). This is trivially
easy to do with bazaar or git, and I'm quite sure that darcs or
mercurial will offer the same comfort level.
At least for my development style, distributed SCM offers one order of
magnitude more comfortable environment than centralized SCM.
As for your concrete sentence, I'd say that if you need a technical tool
as a framework to impose a work flow, then the work flow is possibly
broken. If the work flow is sound, having a tool that eases the work
won't break it.
Regards
Santiago (who was working to deliver this and more info on technical
merits in the community@apache.org thread)
> Thanks,
>
> Dw
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Feb 19, 2008 at 1:06 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Endre Stølsvik wrote:
> > Why should this discussion be moved into a Apache-private realm, and
> > not just stay fully public, so that I can watch the proceedings? This
> > is an interesting discussion.
>
> Can we please keep the Incubator ML focused ???
I'm currently gathering interest [1] about starting an effort at
Apache Labs to further explore ideas related to dSCM at Apache. If
you're interested, you'll find us at labs@labs.apache.org.
[1] http://mail-archives.apache.org/mod_mbox/labs-labs/200802.mbox/%3c510143ac0802200413n59d27aa5h7c9bb12c3b5e001@mail.gmail.com%3e
BR,
Jukka Zitting
---------------------------------------------------------------------
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 Emmanuel Lecharny <el...@gmail.com>.
Endre Stølsvik wrote:
>
> Why should this discussion be moved into a Apache-private realm, and
> not just stay fully public, so that I can watch the proceedings? This
> is an interesting discussion.
Can we please keep the Incubator ML focused ???
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
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 Endre Stølsvik <En...@stolsvik.com>.
Paul Querna wrote:
> Santiago Gala wrote:
>> El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió:
>>> No. This is the wrong forum. What we've said here is that there
>>> won't be any deviation from the ASF infrastructure for source
>>> control; changing ASF infrastructure is out of scope for the Incubator.
>>
>> I already tried to move the discussion to community@apache.org, where I
>> think it belongs, but people insists on answering here. Making requests
>> to a closed team
>
> "Infrastructure" isn't a closed team by any means, and I am tired of
> people propagating that bullshit. Come help, and karma comes.
>
>> in a private list does not accord with *our way of
>> working*, I think. And I don't think there is any need to use a private,
>> unarchived list for discussions on infrastructure improvements.
>
> infrastructure is open to all committers.
> infrastructure-dev is open to all committers.
> infrastructure-private is open to all members.
Why should this discussion be moved into a Apache-private realm, and not
just stay fully public, so that I can watch the proceedings? This is an
interesting discussion.
So far, Santiago has some pretty neat arguments going! :-)
Endre.
---------------------------------------------------------------------
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 Roland Weber <os...@dubioso.net>.
Daniel Kulp wrote:
> On Monday 18 February 2008, Paul Querna wrote:
>>> in a private list does not accord with *our way of
>>> working*, I think. And I don't think there is any need to use a
>>> private, unarchived list for discussions on infrastructure
>>> improvements.
>> infrastructure is open to all committers.
>> infrastructure-dev is open to all committers.
>> infrastructure-private is open to all members.
>>
>> All of them are archived.
>
> None of them are available to see at:
> http://mail-archives.apache.org/mod_mbox/
The EZMLM archives are available to every subscriber.
Send a mail to <listname>-help to get instructions.
There's probably also a way to access raw archives, I'm
sure the folks on infra can tell you how to get there.
The free-for-everyone archives on mail-archives.a.o
are obviously only for list where everyone is allowed
to see the messages, not for committers-only lists.
There is no archive of committers@a.o there either.
cheers,
Roland
---------------------------------------------------------------------
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 Paul Querna <ch...@force-elite.com>.
Daniel Kulp wrote:
> On Monday 18 February 2008, Paul Querna wrote:
>>> in a private list does not accord with *our way of
>>> working*, I think. And I don't think there is any need to use a
>>> private, unarchived list for discussions on infrastructure
>>> improvements.
>> infrastructure is open to all committers.
>> infrastructure-dev is open to all committers.
>> infrastructure-private is open to all members.
>>
>> All of them are archived.
>>
>
> None of them are available to see at:
> http://mail-archives.apache.org/mod_mbox/
>
> Thus, they look pretty private to me.
They are not available on the public web interface, the archives are
available to all committers on people.apache.org.
"private" is an interesting choice of words, but I personally don't
consider them very private with 1600++ committers having access.
Should some or all of them be available on the web interface? I'm not
sure, but bring it up on the infrastructure lists.
-Paul
---------------------------------------------------------------------
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 Daniel Kulp <dk...@apache.org>.
On Monday 18 February 2008, Paul Querna wrote:
> > in a private list does not accord with *our way of
> > working*, I think. And I don't think there is any need to use a
> > private, unarchived list for discussions on infrastructure
> > improvements.
>
> infrastructure is open to all committers.
> infrastructure-dev is open to all committers.
> infrastructure-private is open to all members.
>
> All of them are archived.
>
None of them are available to see at:
http://mail-archives.apache.org/mod_mbox/
Thus, they look pretty private to me.
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
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 Paul Querna <ch...@force-elite.com>.
Santiago Gala wrote:
> El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió:
>> No. This is the wrong forum. What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator.
>
> I already tried to move the discussion to community@apache.org, where I
> think it belongs, but people insists on answering here. Making requests
> to a closed team
"Infrastructure" isn't a closed team by any means, and I am tired of
people propagating that bullshit. Come help, and karma comes.
> in a private list does not accord with *our way of
> working*, I think. And I don't think there is any need to use a private,
> unarchived list for discussions on infrastructure improvements.
infrastructure is open to all committers.
infrastructure-dev is open to all committers.
infrastructure-private is open to all members.
All of them are archived.
HTH,
-Paul
---------------------------------------------------------------------
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 Andrew Savory <an...@luminas.co.uk>.
Hi,
On 2/20/08, Noel J. Bergman <no...@devtech.com> wrote:
> > > This is the wrong forum. What we've said here is that there won't be any
> > > deviation from the ASF infrastructure for source control; changing ASF
> > > infrastructure is out of scope for the Incubator.
>
> > I already tried to move the discussion to community@apache.org, where I
> > think it belongs, but people insists on answering here.
>
> I understand, but that still doesn't make it an issue for the Incubator.
Actually, I'd expect the incubator to be exactly where such
discussions would crop up, as the new blood challenge the status quo
and seek to make sense of how things are done here. And, indeed, this
should be extremely valuable for the community as a whole, as it's a
chance to document our rationales, or to re-evaluate methodologies
that are rendered obsolete by newer technologies.
(Not that I think SVN is obsolete, but I do see some serious value in
reappraising the centralised vs. distributed model of development to
see what is possible within the Apache Way, or even if the Apache Way
should be updated.)
Andrew.
---------------------------------------------------------------------
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 "Noel J. Bergman" <no...@devtech.com>.
Santiago Gala wrote:
> > > - publishing lots of repositories helps surfacing patches that are
> > > currently hidden until ready for sending/committing
> > The last one is almost antithetical to how we want people to work.
> Can you elaborate on how is publishing what currently is hidden
> "antithetical to how we want people to work"? I think that getting a
> clear idea on this is important, as I always thought the ASF was about
> transparency and not keeping information hidden.
Let us clarify, then. I am saying that developers doing extensive work in their own repositories, and periodically merging bulk changes to the communal repository is antithetical to how we want people to work, which is to be working in the shared repository, on a frequent and fine-grained manner, even if in different branches.
> > > The inability of subversion to remember merged results makes working in
> > > a branch unpractical. Been there, done that, very tricky.
> > Raise any technical issues with the Subversion folks.
> huh? why?
Because you are attempting to raise a technical issue regarding our source control system, and they are the ones who would best respond to it.
> > This is the wrong forum. What we've said here is that there won't be any
> > deviation from the ASF infrastructure for source control; changing ASF
> > infrastructure is out of scope for the Incubator.
> I already tried to move the discussion to community@apache.org, where I
> think it belongs, but people insists on answering here.
I understand, but that still doesn't make it an issue for the Incubator.
--- Noel
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió:
> Santiago Gala wrote:
> > I think git-svn abuses the server a lot, as the subversion server is not
> > designed for copying of the whole history.
>
> AFAICS, that's an issue for the Infrastructure Team to address, not the Incubator.
>
> > > Dw wrote:
> > > > I am a bit lost here as well -- what does GiT add to the processes/
> > > > workflows common in the ASF ?
>
> > - faster commits, branch switching, pulls and pushs
> > - merges, good and persistent merges
> > - offline work, offline history diffs
> > - rebasing is not such a "feature", but it can be useful sometimes
> > - publishing lots of repositories helps surfacing patches that are
> > currently hidden until ready for sending/committing
>
> The last one is almost antithetical to how we want people to work. The first few are something that you could raise with the Subversion folks on infra@.
>
Can you elaborate on how is publishing what currently is hidden
"antithetical to how we want people to work"? I think that getting a
clear idea on this is important, as I always thought the ASF was about
transparency and not keeping information hidden. And I think it is in
scope, as the incubator is an important place for people to learn "our
ways".
> > The inability of subversion to remember merged results makes working in
> > a branch unpractical. Been there, done that, very tricky.
>
> Raise any technical issues with the Subversion folks.
>
huh? why?
> > Turning your "key poing" upside down: "We should not try to impose our
> > practices using a technological tool, specially when doing so impairs
> > development."
>
> If there is a better SCM *for our way of working* raise that on infra@, too.
>
> > people *against* changes in SCM is blaming a hypothetical introduction
> > of git of breaking the ASF practices
>
> No. This is the wrong forum. What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator.
I already tried to move the discussion to community@apache.org, where I
think it belongs, but people insists on answering here. Making requests
to a closed team in a private list does not accord with *our way of
working*, I think. And I don't think there is any need to use a private,
unarchived list for discussions on infrastructure improvements.
Regards
Santiago
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 "Noel J. Bergman" <no...@devtech.com>.
Santiago Gala wrote:
> I think git-svn abuses the server a lot, as the subversion server is not
> designed for copying of the whole history.
AFAICS, that's an issue for the Infrastructure Team to address, not the Incubator.
> > Dw wrote:
> > > I am a bit lost here as well -- what does GiT add to the processes/
> > > workflows common in the ASF ?
> - faster commits, branch switching, pulls and pushs
> - merges, good and persistent merges
> - offline work, offline history diffs
> - rebasing is not such a "feature", but it can be useful sometimes
> - publishing lots of repositories helps surfacing patches that are
> currently hidden until ready for sending/committing
The last one is almost antithetical to how we want people to work. The first few are something that you could raise with the Subversion folks on infra@.
> The inability of subversion to remember merged results makes working in
> a branch unpractical. Been there, done that, very tricky.
Raise any technical issues with the Subversion folks.
> Turning your "key poing" upside down: "We should not try to impose our
> practices using a technological tool, specially when doing so impairs
> development."
If there is a better SCM *for our way of working* raise that on infra@, too.
> people *against* changes in SCM is blaming a hypothetical introduction
> of git of breaking the ASF practices
No. This is the wrong forum. What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator.
--- Noel
---------------------------------------------------------------------
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 Santiago Gala <sg...@apache.org>.
El dom, 17-02-2008 a las 10:58 -0500, Noel J. Bergman escribió:
> Dirk-Willem van Gulik wrote:
> > Ross Gardler wrote:
> > > I understand that GiT can be used locally as a layer on top of SVN.
> > > I believe this gives you most of the perceived benefits of GiT
> > > locally without the need for a project itself to switch to GiT.
>
> The issue isn't git as an SVN client. No one (as far as I know) cares what
> SVN client(s) you use, so long as they don't abuse our SVN server.
>
I think git-svn abuses the server a lot, as the subversion server is not
designed for copying of the whole history.
I agree that exporting svn to git/bazaar/mercurial, etc is a way
forward, but it will cause strain to the svn server, for sure. As seen
elsewhere, Jason took this path, and I'm actually using this technique
in a number of places, both with git-svn and bzr-svn. I will keep
reporting.
> > I am a bit lost here as well -- what does GiT add to the processes/
> > workflows common in the ASF ?
>
I already answered to this one in the thread.
- faster commits, branch switching, pulls and pushs
- merges, good and persistent merges
- offline work, offline history diffs
- rebasing is not such a "feature", but it can be useful sometimes
- publishing lots of repositories helps surfacing patches that are
currently hidden until ready for sending/committing
I hope helping each and every developer/contributor counts as helping
the ASF.
> > One of the great things about GiT is that you can can have lots of
> > parallel and non-linear merges (every developer their own branch;
>
> > However in the ASF most groups work roughly along fairly linear lines;
> > with 'one' or just a 'few' points at which a patch is accepted - and
> > essentially few, or just one, merge point (or a single line of merge
> > points when backported). Rarely do we merge multiple 'HEAD's.
>
huh? every "vendor" keeping patches against apache repositories is
merging often. I don't follow your reasoning, anybody keeping patches is
merging repeatedly against a moving HEAD (for active projects). In my
view, every developer that maintains patches is in effect having a
*private, unpublished* branch. With git and a setup like the one in
kernel.org, all those patches are suddenly public, visible. Think about
it.
> And most importantly, we want our development to be visible to the
> Community, not done in private and committed when finished. Developers can
> always make more or less transient branches to work on code, still in public
> view, and merge back to shared locations. The key point here that I believe
> you, I, William and others are all making isn't about technology, it is
> about practice.
>
The inability of subversion to remember merged results makes working in
a branch unpractical. Been there, done that, very tricky.
Personal repositories can be kept in public, you just can look into the
different branches in http://git.kernel.org/?p=linux/kernel to see how a
number of those are updated a lot.
Turning your "key poing" upside down: "We should not try to impose our
practices using a technological tool, specially when doing so impairs
development."
> Now, if there is an SCM that substantially improves the ASF's ability to
> perform *our* practices, that is a separate discussion item.
>
I'm quite sure currently any one of git, bazaar, mercurial or even darcs
would improve our practices.
Just to make sure, my view of the discussion:
people *against* changes in SCM is blaming a hypothetical introduction
of git of breaking the ASF practices
I don't think the discussion is, and never was presented as:
evil revolutionaries wanting to break the practices by introduction of
sneaky "solipsistic" tools.
I don't think git will break ASF practices more than keeping quilt
patches, or several repositories, to survive "svn up" without nasty
conflicts.
Regards
Santiago
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
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 "Noel J. Bergman" <no...@devtech.com>.
Dirk-Willem van Gulik wrote:
> Ross Gardler wrote:
> > I understand that GiT can be used locally as a layer on top of SVN.
> > I believe this gives you most of the perceived benefits of GiT
> > locally without the need for a project itself to switch to GiT.
The issue isn't git as an SVN client. No one (as far as I know) cares what
SVN client(s) you use, so long as they don't abuse our SVN server.
> I am a bit lost here as well -- what does GiT add to the processes/
> workflows common in the ASF ?
> One of the great things about GiT is that you can can have lots of
> parallel and non-linear merges (every developer their own branch;
> However in the ASF most groups work roughly along fairly linear lines;
> with 'one' or just a 'few' points at which a patch is accepted - and
> essentially few, or just one, merge point (or a single line of merge
> points when backported). Rarely do we merge multiple 'HEAD's.
And most importantly, we want our development to be visible to the
Community, not done in private and committed when finished. Developers can
always make more or less transient branches to work on code, still in public
view, and merge back to shared locations. The key point here that I believe
you, I, William and others are all making isn't about technology, it is
about practice.
Now, if there is an SCM that substantially improves the ASF's ability to
perform *our* practices, that is a separate discussion item.
--- Noel
---------------------------------------------------------------------
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 Dirk-Willem van Gulik <di...@webweaving.org>.
On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:
> Noel J. Bergman wrote:
>> J Aaron Farr wrote:
>>> J Aaron Farr wrote:
>>>>> git could be an issue.
>>>> Can you explain what the issue is with Git?
>>> Leo already gave a decent explanation.
>>> Basically, it comes down to two aspects:
>>> 1) infrastructure support
>>> 2) cultural bias
>> Only the first one is marginally correct, IMO.
>> Santiago wrote:
>>>> 1. You have to use subversion.
>
>
> Sorry, I've missed the thread that led to this, so sorry if I'm
> repeating others.
>
> I understand that GiT can be used locally as a layer on top of SVN.
> I believe this gives you most of the perceived benefits of GiT
> locally without the need for a project itself to switch to GiT.
I am a bit lost here as well -- what does GiT add to the processes/
workflows common in the ASF ?
One of the great things about GiT is that you can can have lots of
parallel and non-linear merges (every developer their own branch; lots
of people merging the same patch into different sequences) -- and as
such I can see it being perfectly tuned for, say, Linux.
However in the ASF most groups work roughly along fairly linear lines;
with 'one' or just a 'few' points at which a patch is accepted - and
essentially few, or just one, merge point (or a single line of merge
points when backported). Rarely do we merge multiple 'HEAD's.
And I'd almost argue that SVN is a useful framework which helps us
stay on the paved roads - where a single head progresses with group
consensus and generally agreed merit.
Thanks,
Dw
---------------------------------------------------------------------
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 Aidan Skinner <ai...@apache.org>.
On Thu, Feb 14, 2008 at 11:25 AM, Ross Gardler <rg...@apache.org> wrote:
> I understand that GiT can be used locally as a layer on top of SVN. I
> believe this gives you most of the perceived benefits of GiT locally
> without the need for a project itself to switch to GiT.
>
> Now, I've never tried this and don't know anyone who has, but thought
> I'd flag it in case it is relevant.
My 2p:
I've been doing this recently with qpid, partly because I'm wrangling
a large merge at the moment (which it does better than straight svn)
and partly because it suits my typical workflow a bit better: cheap
local branching means I can hack on something, get interrupted, create
another branch to work on that interruption in isolation, commit that
to HEAD, rebase the branch from the first thing and pick up where I
left off without having to take intermediate patches, revert that out,
reapply etc which is what I did before.
The initial import is ridiculouisly slow if you take all the history
because the asf has one repo for all the projects and it looks at each
revision, but you can tell it to only pull history from a certain
point.
- Aidan
--
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"Almost everything is imitation... The most original writers borrowed
from one another." - Voltaire
---------------------------------------------------------------------
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 Ross Gardler <rg...@apache.org>.
Noel J. Bergman wrote:
> J Aaron Farr wrote:
>> J Aaron Farr wrote:
>>>> git could be an issue.
>>> Can you explain what the issue is with Git?
>> Leo already gave a decent explanation.
>> Basically, it comes down to two aspects:
>> 1) infrastructure support
>> 2) cultural bias
>
> Only the first one is marginally correct, IMO.
>
> Santiago wrote:
>>> 1. You have to use subversion.
Sorry, I've missed the thread that led to this, so sorry if I'm
repeating others.
I understand that GiT can be used locally as a layer on top of SVN. I
believe this gives you most of the perceived benefits of GiT locally
without the need for a project itself to switch to GiT.
Now, I've never tried this and don't know anyone who has, but thought
I'd flag it in case it is relevant.
Ross
---------------------------------------------------------------------
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 Brian McCallister <br...@skife.org>.
FWIW, I quite like both git and mercurial, both give me a better workflow
than subversion for a lot of things I work on. Offline commits, local
branches, and sane merging are *huge*. The approach to distributed repos is
also very nice for folks who do want to maintain a fork elsewhere (forking
isn't evil, it is a very good reaction to needing something slightly
different which the majority (or the powerful) in the base project doesn't
want).
Looking forward to trying svn 1.5 branch management, though :-) Being able
to repeatedly merge from a branch I didn't branch from will be *huge* (ie,
pull bug fixes from release branches without pulling cruft from trunk from
whence I branched).
I quite accept the practical side of saying "svn only" as long as no one
steps up to manage git or mercurial. Saying "though shalt use svn because it
is the blessed end-all" is BS. Subversion is great, and all, but it also
sucks. Some things suck less for different workflows, some things suck more.
For one-branch development, svn is awesome.
Saying we can have only one "because" is very weak. Can anyone cite specific
problems FreeBSD or Perl have had?
-Brian