Feature #2033: Move Core Development to Git

• Status: Closed
• Assignee: yugui (Yuki Sonoda)

[runpaint (Run Paint Run Run)]

=begin
Following from [ruby-core:21039], I formally propose that core development switches to Git. The obvious benefits include:

• Opens Ruby development to a wider range of contributors. Ruby- and non-Ruby-based projects alike have shown a dramatic upswing in contributions after moving to Git.
• Allows tickets to be handled by de facto topic branch maintainers. A contributor interested in improving documentation, for example, could review the documentation tickets, apply the relevant patches to his 'doc' branch, then propose it be merged periodically. The core team could, and should, still monitor this branch's progress, and intercede where necessary. Ultimately, development would suffer less from the current bottleneck effect, allowing contributers to play a larger role.
• Complicated feature proposals would take the form of branches. This solves the current problem of patches rotting in Redmine because rebase and Git's superior merging capability allow the patch to be kept in step with the trunk. Further, this allows parties interested in the feature to collaborate on the branch; only submitting a pull request when they deem it mature.
• Experimentation is encouraged because now anybody can branch, and contribute back that branch, with impunity.
• Working with the trunk becomes more pleasurable due to Git's advanced toolset and significant performance benefits.

Etcetera. I am particularly excited about the options that Git would give us to decentralize development: spreading the workload over a wider number of contributors, while still retaining the core team's vital role as gatekeepers. Redmine tickets alone suggest that the current path is not maintainable; the sooner we change our course, the easier the process will be.

In the previous ruby-core thread on this matter matz's sole objection was that certain scripts exist for the SVN workflow that would need porting to Git. If this is still the case, perhaps the scripts could be posted publicly so interested parties could port them? What objections remain?
=end

[hongli (Hongli Lai)]

=begin
I support this idea.
=end

[bitsweat (Jeremy Daer)]

=begin
Strongly agreed. Switching to git was a turning point for Rails development also.

There's a full svn mirror at http://github.com/shyouhei/ruby to start using today.
=end

[wycats (Yehuda Katz)]

=begin
I agree with this, and I think ruby-core wants to do this as well. I'll personally step up and agree to spend time moving the tools over. I think we could probably get a commitment from other folks as well (including some folks at GitHub, I'd guess).

So, where are they :)
=end

[foca (Nicolás Sanguinetti)]

=begin
Yes. This would be great for ruby IMO.
=end

[naruse (Yui NARUSE)]

=begin
Some commiter of Ruby live on Windows.
And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
So we can't move to git.

those benefits seem to be resolved by shyouhei's ruby in github.
If you fork his and publish your patch, we can take it.
(Of course, they must be well commented)
=end

[febuiles (Federico Builes)]

=begin
+1 to this.

As I said in the original thread, I'll be glad to help porting any tools to the new system.
=end

[luislavena (Luis Lavena)]

=begin
On Wed, Sep 2, 2009 at 8:57 PM, Yehuda [e-mail] wrote:

Issue #2033 has been updated by Yehuda Katz.

I agree with this, and I think ruby-core wants to do this as well. I'll personally step up and agree to spend time moving the tools over. I think we could probably get a commitment from other folks as well (including some folks at GitHub, I'd guess).

So, where are they :)

According to 'tweets' there has been the rumor that Ruby-core do not
migrate to Git due lack of Windows support.

I must say that is completely inaccurate.

Git support has been excellent using msysGit releases, even with
integrated git-svn support.

Projects like rake-compiler and RubyInstaller uses Git and GitHub as
SCM and contribution platform, something we couldn't achieve using
Subversion.

In my humble opinion, the move to Git will highly increase the options
for people wanting to contribute to Ruby.

Regards,

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[ebianco (Enrico Bianco)]

=begin
I strongly agree with this proposal.

Using Git with Windows is much easier than it used to be. Perhaps moving Ruby development from SVN to Git would even serve as a strong motivator to improve the Windows port of Git!
=end

[igrigorik (Ilya Grigorik)]

=begin
+1

I would also strongly encourage github as an option, instead of running own servers. To me, the main benefit of the switch is not even necessarily in Git vs SVN as much as in the transparency that it would enable. Let's face it, most of us are on GitHub already, following a ton of projects. Having Ruby there would just make sense.
=end

[luislavena (Luis Lavena)]

=begin
On Wed, Sep 2, 2009 at 10:00 PM, Ilya [e-mail] wrote:

I would also strongly encourage github as an option, instead of running own servers.

With Git it doesn't matter, is just another remote to pull/merge or
cherry-pick from.

To me, the main benefit of the switch is not even necessarily in Git vs SVN as much as in the transparency that it would enable. Let's face it, most of us are on GitHub already, following a ton of projects. Having Ruby there would just make sense.

I follow Ruby SVN using RSS and I must say that doing that way really
confuses me.

The RSS links points to cvscgi views, while Redmine points to
integrated commits.

I think depends on the level of integration that can be achieved with
Redmine which is going to decide the "origin" repository.

--
Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[jonforums (Jon Forums)]

=begin

Some commiter of Ruby live on Windows.
And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
So we can't move to git.

As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable. While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.

The only difficulty I've had so far is the age old issue of line endings, which is easily solved by setting "core.autocrlf = false" globally. I use an editor (gvim) that understands both styles of line endings and there are many other good editors (free and non-free) on Windows that do the same.

Have any of the Ruby-committers-living-on-Windows actually had any specific problems with msysgit?

Jon

=end

[drbrain (Eric Hodel)]

=begin
On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:

Feature #2033: Move Core Development to Git
http://redmine.ruby-lang.org/issues/show/2033

Author: Run Paint Run Run
Status: Open, Priority: Normal
Assigned to: Yukihiro Matsumoto

Following from [ruby-core:21039], I formally propose that core
development switches to Git. The obvious benefits include:

• Opens Ruby development to a wider range of contributors. Ruby- and
  non-Ruby-based projects alike have shown a dramatic upswing in
  contributions after moving to Git.

This is scientifically proven?

• Allows tickets to be handled by de facto topic branch maintainers.
  A contributor interested in improving documentation, for example,
  could review the documentation tickets, apply the relevant patches
  to his 'doc' branch, then propose it be merged periodically. The
  core team could, and should, still monitor this branch's progress,
  and intercede where necessary. Ultimately, development would suffer
  less from the current bottleneck effect, allowing contributers to
  play a larger role.

This sounds like more work than what happens now. How is more work
supposed to make ruby development faster?

• Complicated feature proposals would take the form of branches.
  This solves the current problem of patches rotting in Redmine
  because rebase and Git's superior merging capability allow the
  patch to be kept in step with the trunk. Further, this allows
  parties interested in the feature to collaborate on the branch; only
  submitting a pull request when they deem it mature.

Can't this be done now with git-svn?

• Experimentation is encouraged because now anybody can branch, and
  contribute back that branch, with impunity.

Ditto.

• Working with the trunk becomes more pleasurable due to Git's
  advanced toolset and significant performance benefits.

I've found git less pleasurable and it's "advanced" toolset cumbersome
and unfriendly. It's largely been a performance detriment to me.

=end

[igrigorik (Ilya Grigorik)]

=begin
+1

I would also strongly encourage github as an option, instead of running own servers. To me, the main benefit of the switch is not even necessarily in Git vs SVN as much as in the transparency that it would enable. Let's face it, most of us are on GitHub already, following a ton of projects. Having Ruby there would just make sense.
=end

[runpaint (Run Paint Run Run)]

=begin

• Opens Ruby development to a wider range of contributors. Ruby- and
  non-Ruby-based projects alike have shown a dramatic upswing in contributions
  after moving to Git.

This is scientifically proven?

Heh, I confess not to have orchestrated a wide-scale statistical study
on the matter, no. The anecdotal evidence, however, is very much in
keeping with my claim. The experience of Rails
(http://www.igvita.com/2009/01/27/ruby-swarms-visualizing-rails-git/)
and the Linux kernel
(http://www.linuxfoundation.org/publications/whowriteslinux.pdf)
mirror those of other major projects which made the transition. If you
require numerical arguments to be convinced, I will endeavor to
assemble the requisite data.

• Allows tickets to be handled by de facto topic branch maintainers. A
  contributor interested in improving documentation, for example, could review
  the documentation tickets, apply the relevant patches to his 'doc' branch,
  then propose it be merged periodically. The core team could, and should,
  still monitor this branch's progress, and intercede where necessary.
  Ultimately, development would suffer less from the current bottleneck
  effect, allowing contributers to play a larger role.

This sounds like more work than what happens now.  How is more work supposed
to make ruby development faster?

It is indeed more work than happens now. Now being the time of severe
ticket backlogs on Redmine (the statistics for which I cannot provide
as Redmine is, again, unresponsive), and more requests than I have the
decency to reference languishing without so much as an acknowledgment.
I am but an insignificant player, yet can vouch that I have a
multitude of tickets in my buffer which remain locally because
similar, submitted requests have been left to perish. The workflow we
propose will alleviate this situation by distributing this work to
extra and eager pairs of hands. It will require slightly more work to
the benefit of significantly more progress.

• Complicated feature proposals would take the form of branches. This
  solves the current problem of patches rotting in Redmine because rebase
  and Git's superior merging capability allow the patch to be kept in step
  with the trunk. Further, this allows parties interested in the feature to
  collaborate on the branch; only submitting a pull request when they deem it
  mature.

Can't this be done now with git-svn?

Such an approach can be poorly approximated by an intermediate user of
said gateway. But as the MBARI patches, the recent interest in the
win32-unicode branch, my trifling work on Onigurma, and many more
cases in recent memory serve to illustrate, this process is clumsy and
inelegant.

Put simply, while git-svn may flawlessly translate SVN to Git; the
converse can never be true: Git users must degrade their work, casting
aside the rich metadata Git supplies, so SVN can stomach it. Your
argument may be more properly put if reversed: Can the few who prefer
to retain the SVN toolset be accommodated by git-svn in conjunction
with a Git repository? Why yes, they can.

• Working with the trunk becomes more pleasurable due to Git's advanced
  toolset and significant performance benefits.

I've found git less pleasurable and it's "advanced" toolset cumbersome and
unfriendly.  It's largely been a performance detriment to me.

Perhaps if you could explain your difficulties, we may assist you in
overcoming them? If you desire to use Git as SVN, the interface is so
similar, that if one establishes compatiability aliases, the key
remaining difference is Git's superior speed. By "performance
benefits", I was referring to these magnificent speed benefits, which
are especially noticeable with large repositories such as Ruby's. :-)

=end

[igrigorik (Ilya Grigorik)]

=begin
+1

I would also strongly encourage github as an option, instead of running own servers. To me, the main benefit of the switch is not even necessarily in Git vs SVN as much as in the transparency that it would enable. Let's face it, most of us are on GitHub already, following a ton of projects. Having Ruby there would just make sense.
=end

[bitsweat (Jeremy Daer)]

=begin
On Wed, Sep 2, 2009 at 4:29 PM, Eric [e-mail] wrote:

On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:

Feature #2033: Move Core Development to Git
http://redmine.ruby-lang.org/issues/show/2033

Author: Run Paint Run Run
Status: Open, Priority: Normal
Assigned to: Yukihiro Matsumoto

Following from [ruby-core:21039], I formally propose that core development
switches to Git. The obvious benefits include:

• Opens Ruby development to a wider range of contributors. Ruby- and
  non-Ruby-based projects alike have shown a dramatic upswing in contributions
  after moving to Git.

This is scientifically proven?

That's a good line. I assume you're using it rhetorically. The
proposal deserves good-faith consideration.

An observation or three:

Rails saw a surge in number of contributors, number of patches, and
patch quality after moving to git. Several contributors naturally
emerged as vetters and integrators. This widened the patch-examination
bottleneck by naturally spreading the responsibility among other
trusted contributors. No organization was required; this pleasantly
emerged as a property of the system.

I think number of contributors and patches went up just due to
transparency, accessibility, and responsiveness. It's hard to say, but
GitHub had a significant role here. I think patch quality has
increased largely because rebasing a topic branch against the main
line is extremely easy. Old fixes don't go stale.

Furthermore, we recently had an incredible experience with the first
RailsBridge bug mash:
http://wiki.railsbridge.org/projects/1/wiki/BugMash. Git was by no
means the reason for its success, but it acted as a strong enabler.
New users understood the workflow and tools with little trouble;
within two days we'd see 37 first-time contributors' patches applied
to master and hundreds of others'. We hope to repeat the experiment
before every stable gem release.

I was skeptical about moving from svn to git, but it has paid off big
time and in ways I hadn't anticipated. I've completely come around.

• Allows tickets to be handled by de facto topic branch maintainers. A
  contributor interested in improving documentation, for example, could review
  the documentation tickets, apply the relevant patches to his 'doc' branch,
  then propose it be merged periodically. The core team could, and should,
  still monitor this branch's progress, and intercede where necessary.
  Ultimately, development would suffer less from the current bottleneck
  effect, allowing contributers to play a larger role.

This sounds like more work than what happens now.  How is more work supposed
to make ruby development faster?

It's more apparent work, of course, but broadly and naturally
distributed among contributors of varying skill and interest using
tools honed for just this purpose.

• Complicated feature proposals would take the form of branches. This
  solves the current problem of patches rotting in Redmine because rebase
  and Git's superior merging capability allow the patch to be kept in step
  with the trunk. Further, this allows parties interested in the feature to
  collaborate on the branch; only submitting a pull request when they deem it
  mature.

Can't this be done now with git-svn?

It can, with caveats. You have to shove everything back through the svn funnel.

• Experimentation is encouraged because now anybody can branch, and
  contribute back that branch, with impunity.

Ditto.

Same.

• Working with the trunk becomes more pleasurable due to Git's advanced
  toolset and significant performance benefits.

I've found git less pleasurable and it's "advanced" toolset cumbersome and
unfriendly.  It's largely been a performance detriment to me.

For decentralized development, cheap, effective branching and merging
is awesome and desperately needed. Git and many other SCMs beat the
pants off Subversion in this respect, and this alone is worth it.

In the interest of productive discussion about the topic at hand --
moving from svn to git -- I think we're all be best off discontinuing
a vim/emacsish discussion of whether git is "your style."

Best,
jeremy

=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed

=begin
http://wiki.github.com/shyouhei/ruby/committerhowto
=end

[nobu (Nobuyoshi Nakada)]

=begin
And http://wiki.github.com/shyouhei/ruby/noncommitterhowto
=end

[marcandre (Marc-Andre Lafortune)]

=begin
I'll only add to the compelling arguments presented so far a very enthousiastic "+1".
=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Closed to Open

=begin

=end

[matz (Yukihiro Matsumoto)]

• Assignee changed from matz (Yukihiro Matsumoto) to yugui (Yuki Sonoda)

=begin
I think there's need a lot of work to do, like better Windows git port, moving svn based tools to git, etc.
=end

[luislavena (Luis Lavena)]

=begin
On Thu, Sep 3, 2009 at 6:26 AM, Yukihiro [e-mail] wrote:

Issue #2033 has been updated by Yukihiro Matsumoto.

Assigned to changed from Yukihiro Matsumoto to Yuki Sonoda

I think there's need a lot of work to do, like better Windows git port, moving svn based tools to git, etc.

Dear Matz,

I would really like to know what are the limitation experienced using
Git on Windows that this perception of "not good enough" keep
appearing repeated times?

Perhaps this happens in the japanesse list, so would love and
appreciate someone take a couple of minutes to express those in
english.

Maybe as a community we can help solve those and improve the Windows Git port.

Thank you.

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[matz (Yukihiro Matsumoto)]

=begin

In message "Re: [ruby-core:25313] Re: [Feature #2033] Move Core Development to Git"
on Thu, 3 Sep 2009 16:02:38 +0900, Ron Mayer [e-mail] writes:

|Maybe as a small step in this direction the ruby project could first
|publish an official svn->git conversion of their own (or adopt the
|one on github.com/rubyspec) and insure that it's kept up-to-date?

For various reasons, we cannot move to git at once, so as a small
step, use git://github.com/shyouhei/ruby.git. See

http://wiki.github.com/shyouhei/ruby/committerhowto
http://wiki.github.com/shyouhei/ruby/noncommitterhowto

						matz.

=end

[hramrach (Michal Suchanek)]

=begin
2009/9/3 Yukihiro Matsumoto [e-mail]:

In message "Re: [ruby-core:25313] Re: [Feature #2033] Move Core Development to Git"
   on Thu, 3 Sep 2009 16:02:38 +0900, Ron Mayer [e-mail] writes:

|Maybe as a small step in this direction the ruby project could first
|publish an official svn->git conversion of their own (or adopt the
|one on github.com/rubyspec) and insure that it's kept up-to-date?

For various reasons, we cannot move to git at once, so as a small
step, use git://github.com/shyouhei/ruby.git.  See

http://wiki.github.com/shyouhei/ruby/committerhowto
http://wiki.github.com/shyouhei/ruby/noncommitterhowto

                                                       matz.

I guess that's a good start.

Recent experience with git and git-svn shows that there is a wide gap
between having an official upstream git repository and locally
mirroring an upstream svn with git-svn.

Thanks

Michal

=end

[jonforums (Jon Forums)]

=begin

Maybe as a community we can help solve those and improve the Windows Git port.

Thank you.

Luis Lavena
AREA 17

I found the following blog helpful when I was first evaluating msysgit:

http://www.lostechies.com/blogs/jason_meridth/archive/2009/06/01/git-for-windows-developers-git-series-part-1.aspx

I initially avoid installers like the plague until they prove themselves by not trashing my system.

As such, I started with the 7-zipped PortableGit version and have had a very good experience with the following setup on my Windows systems (I've not used the msysgit installer so I have no advice one way or the other on it)

• unzip to any directory without a space in the pathname...<GIT_INSTALL> from now on.
• add <GIT_INSTALL>\cmd to %PATH%
• generate keys via "ssh-keygen" from the Git-Bash prompt using <GIT_INSTALL>\git-bash.bat. This correctly creates a ".ssh" dir containing your keys in the right place.
• set up global config with name, email, aliases, diff/merge tools like kdiff3, etc as well as set "core.autocrlf = false" (VERY IMPORTANT)
• upload keys to Github, gitorious, etc.
• start cloning, hacking, merging, branching...
• use either Git-Bash or standard cmd.exe for cmd line git

While I found some of Git's idioms and naming conventions strange at first, being able to type things like "git help reset" and have decent docs pop up in my browser have been great for shortening my learning curve.

So far so good for me as a user of both msysgit and git.

Jon

=end

[runpaint (Run Paint Run Run)]

=begin

I would really like to know what are the limitation experienced using
Git on Windows that this perception of "not good enough" keep
appearing repeated times?

Indeed. Windows support is seeming more and more like a paper tiger. We have experienced Windows developers telling us that the current situation is reasonable, and the anecdotes I've found online are along the same lines. Before this argument is repeated can it be clarified?

moving svn based tools to git

Please could these tools be named? In the tool/ directory of trunk only make-snapshot appears to both rely on SVN and not support Git. Where are the others?

I think there's need a lot of work to do

It would help if we could enumerate it. If we can compile a list we can determine our next steps.
=end

[stepheneb (Stephen Bannasch)]

=begin
I think moving to git would be great.

Some concerns expressed by Matz:

moving svn based tools to git
I think there's need a lot of work to do

It would help if we could enumerate it. If we can compile a list we can determine our next steps.

One type of work is adapting or removing sections of code that use or depend on subversion keyword expansion.

See one example here:

fixed crash in lib/logger.rb from dependency on svn keywork expansion
http://redmine.ruby-lang.org/issues/show/1978

I don't think fixing these kind of problems is very hard ... but I haven't made any estimate of how big the task is.

=end

[shyouhei (Shyouhei Urabe)]

=begin
Jon wrote:

Some commiter of Ruby live on Windows.
And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
So we can't move to git.

As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable. While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.

That's not the point. The problem on msysGit is that it IS a preview. It's
not a matter of stability. We cannot believe a preview product especially when
that preview software is a fundamental tool to us, such as git.

=end

[hramrach (Michal Suchanek)]

=begin
2009/9/4 Urabe Shyouhei [e-mail]:

Jon wrote:

Some commiter of Ruby live on Windows.
And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
So we can't move to git.

As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable.  While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.

That's not the point.  The problem on msysGit is that it IS a preview.  It's
not a matter of stability.  We cannot believe a preview product especially when
that preview software is a fundamental tool to us, such as git.

And if I made a new site that offered the same package and labeled it
final would you trust it then?

What is preview or final or stable is relative to the developer
releasing the package.

At the very least

• this preview package has been tested by people writing here (and
  probably many more elsewhere) so it can be labeled final by popular
  vote

• people who insist on doing so can still use a SVN mirror

Thanks

Michal

=end

[shyouhei (Shyouhei Urabe)]

=begin
Michal Suchanek wrote:

2009/9/4 Urabe Shyouhei [e-mail]:

Jon wrote:

Some commiter of Ruby live on Windows.
And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
So we can't move to git.
As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable. While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.
That's not the point. The problem on msysGit is that it IS a preview. It's
not a matter of stability. We cannot believe a preview product especially when
that preview software is a fundamental tool to us, such as git.

And if I made a new site that offered the same package and labeled it
final would you trust it then?

I can then evaluate that software. You know, whether a release is final or not
is aside form whether I trust it or not.

What is preview or final or stable is relative to the developer
releasing the package.

Yes. Trusting a software includes trusting its developer. How can you trust
it when you cannot trust its creator? I suspect there're reasons for the
developer to say it's still a preview. And I trust she/he on that.

At the very least

• this preview package has been tested by people writing here (and
  probably many more elsewhere) so it can be labeled final by popular
  vote

Maybe. But can those people see to that? We are not choosing our wall clocks.
A source code management system is vital to an open source software community.
I know you remember our repository was once cracked when we used CVS.

• people who insist on doing so can still use a SVN mirror

You're saying to move to Git while mirroring that Git repo with SVN? Can that
be possible?

=end

[shyouhei (Shyouhei Urabe)]

=begin
Ruby is a basic infrastructure that needs to be stable. If it goes as agile as
Rails, there should be problems. A problem may be the hardness for Rails to
catch-up with Ruby, when both of them are equally as agile.

So sorry but I don't like the idea for Ruby to move into a fully decentralized
development. There should be at least one single center of Ruby as we have
today. And as a centralized development tool, Subversion is the best thing we
have.

I think a centralized SVN repo + official git-svn mirror is the best way for
ruby because that should suit for its characteristics and development style.
Most claims from git enthusiasts can be met with a git-svn mirror I believe.
The only thing that cannot be met may be "to make ruby git based anyway" kind
of groundless request.

=end

[zenspider (Ryan Davis)]

=begin

On Sep 3, 2009, at 16:44 , Urabe Shyouhei wrote:

Ruby is a basic infrastructure that needs to be stable. If it goes
as agile as
Rails, there should be problems. A problem may be the hardness for
Rails to
catch-up with Ruby, when both of them are equally as agile.

So sorry but I don't like the idea for Ruby to move into a fully
decentralized
development. There should be at least one single center of Ruby as
we have
today. And as a centralized development tool, Subversion is the
best thing we
have.

I think a centralized SVN repo + official git-svn mirror is the best
way for
ruby because that should suit for its characteristics and
development style.
Most claims from git enthusiasts can be met with a git-svn mirror I
believe.
The only thing that cannot be met may be "to make ruby git based
anyway" kind
of groundless request.

間違いない

Urabeさんは私の太陽、私の星、私の月です

Urabeさんが大好きです

=end

[febuiles (Federico Builes)]

=begin
Hello Urabe,

On Sep 3, 2009, at 6:44 PM, Urabe Shyouhei wrote:

Ruby is a basic infrastructure that needs to be stable. If it goes
as agile as
Rails, there should be problems. A problem may be the hardness for
Rails to
catch-up with Ruby, when both of them are equally as agile.

Is this issue really related to the SCM that the project uses?

Many projects have had an increase in their number of collaborators
when they moved to Git, but that doesn't mean that no one will be in
charge and that it will be moving so fast that projects like Rails
won't be able to keep up with it (I'm not entirely sure that I got
your point there).

So sorry but I don't like the idea for Ruby to move into a fully
decentralized
development. There should be at least one single center of Ruby as
we have
today. And as a centralized development tool, Subversion is the
best thing we
have.

Excuse my lack of knowledge in this matter, but what prevents ruby-
core from maintaining a canonical Ruby Git repository hosted in the
same servers that SVN resides in right now (or in Github if you don't
want to go through the admin. hassle)?
You can still give commit access only to your list of trusted members
and this "central" repository will be the one that everyone pulls off
when they want to get the official version.
What does SVN gives you that Git misses in this case?

I think a centralized SVN repo + official git-svn mirror is the best
way for
ruby because that should suit for its characteristics and
development style.

I would really appreciate it if you could be more specific in the
"characteristics and development style" that SVN fits so well and that
Git doesn't.

Most claims from git enthusiasts can be met with a git-svn mirror I
believe.

An official git-svn mirror would be greatly appreciated, it would be
better than the current situation, but can't we "have the cake and eat
it too"?

Thanks

--
Federico

=end

[hramrach (Michal Suchanek)]

=begin
2009/9/4 Urabe Shyouhei [e-mail]:

 - people who insist on doing so can still use a SVN mirror

You're saying to move to Git while mirroring that Git repo with SVN?  Can that
be possible?

That's certainly possible. SVN can store any code git can. It just
lacks the tools for working with the code and I would be surprised if
there was no tool for importing changesets from git to SVN.

However, there's not much difference between having a official SVN
repository and official git mirror or the other way around for the
outside world. Perhaps making git the primary repository would make it
easier for some of the core developers to use git's additional
features not available in svn. However, that's a decision for Ruby
core developers if they want these features or not.

Thanks

Michal

=end

[drbrain (Eric Hodel)]

=begin
On Sep 2, 2009, at 17:38, Run Paint Run Run wrote:

• Opens Ruby development to a wider range of contributors. Ruby- and
  non-Ruby-based projects alike have shown a dramatic upswing in
  contributions
  after moving to Git.

This is scientifically proven?

Heh, I confess not to have orchestrated a wide-scale statistical study
on the matter, no. The anecdotal evidence, however, is very much in
keeping with my claim. The experience of Rails
(http://www.igvita.com/2009/01/27/ruby-swarms-visualizing-rails-git/)

None of my contributions from the svn days showed up here. It seems
to be biased towards git simply due to lack of data.

I had a patch for Rails sit around until it rotted simply because
nobody bothered to communicate back the few problems that existed in
it. I don't think git magically solved the problem of Rails
developers not caring about contributions. I'm more willing to
believe DHH releasing his stranglehold on committers (to the central
repository) was the real change here.

and the Linux kernel
(http://www.linuxfoundation.org/publications/whowriteslinux.pdf)
mirror those of other major projects which made the transition.

I would hope that the tool designed for the linux kernel development
workflow would make linux kernel development work well.

• Allows tickets to be handled by de facto topic branch
  maintainers. A
  contributor interested in improving documentation, for example,
  could review
  the documentation tickets, apply the relevant patches to his 'doc'
  branch,
  then propose it be merged periodically. The core team could, and
  should,
  still monitor this branch's progress, and intercede where necessary.
  Ultimately, development would suffer less from the current
  bottleneck
  effect, allowing contributers to play a larger role.

This sounds like more work than what happens now. How is more work
supposed
to make ruby development faster?

It is indeed more work than happens now. Now being the time of severe
ticket backlogs on Redmine (the statistics for which I cannot provide
as Redmine is, again, unresponsive), and more requests than I have the
decency to reference languishing without so much as an acknowledgment.

Ruby has a ticket system now so fixes to problems and backlogged
problems are much more visible. It didn't used to be this way, it used
to appear that all problems were backlogged.

I am but an insignificant player, yet can vouch that I have a
multitude of tickets in my buffer which remain locally because
similar, submitted requests have been left to perish. The workflow we
propose will alleviate this situation by distributing this work to
extra and eager pairs of hands. It will require slightly more work to
the benefit of significantly more progress.

You've done a lot of good work for Ruby. You should ask for a commit
bit. IMO you deserve it. It's usually this easy:

1. show you can contribute useful stuff
2. ask for a commit bit
3. commit (maybe occasionally asking if it's ok when you're unsure)

It's as if git will make people less shy about asking to get directly
involved. If you're going to go to be continually writing patches is
it really that hard to ask for a commit bit? It's not like you're
getting turned down for a date.

• Working with the trunk becomes more pleasurable due to Git's
  advanced
  toolset and significant performance benefits.

I've found git less pleasurable and it's "advanced" toolset
cumbersome and
unfriendly. It's largely been a performance detriment to me.

Perhaps if you could explain your difficulties, we may assist you in
overcoming them? If you desire to use Git as SVN, the interface is so
similar, that if one establishes compatiability aliases, the key
remaining difference is Git's superior speed. By "performance
benefits", I was referring to these magnificent speed benefits, which
are especially noticeable with large repositories such as Ruby's. :-)

Today a coworker of mine was pulling from upstream and ran into a
conflict. (If you just push and assume everything is ok git doesn't
say "please pull, there are conflicts" it says something like "can't
fast-forward" which is far less clear than the former.)

He resolved the conflict and ran git commit then git rebase -- continue which proceeded to give a very unclear error message.
Instead of git commit he should have used git add, but git
couldn't be bothered to tell him that he probably didn't want to do
that.

On the other hand, if I have a conflict in subversion or perforce I
get a very helpful interactive resolving tool that lets me
interactively merge conflicts or bring up my favorite editor for
involved conflicts.

If I walk away from my computer in the middle of a conflict and come
back later I can easily figure out where to continue with subversion,
perforce, even CVS. This isn't guaranteed with git (git add but
don't git rebase --continue? your only clue is something like "not
on any branch" in git status).

I've found that for the 90% use case of a VCS (committing software to
a shared repository), git makes me do more work. Advanced tools
should make me do less work.

PS: Perforce does branching and merging better.

=end

[shyouhei (Shyouhei Urabe)]

=begin
Federico Builes wrote:

Hello Urabe,

On Sep 3, 2009, at 6:44 PM, Urabe Shyouhei wrote:

Ruby is a basic infrastructure that needs to be stable. If it goes as
agile as
Rails, there should be problems. A problem may be the hardness for
Rails to
catch-up with Ruby, when both of them are equally as agile.

Is this issue really related to the SCM that the project uses?

Many projects have had an increase in their number of collaborators when
they moved to Git, but that doesn't mean that no one will be in charge
and that it will be moving so fast that projects like Rails won't be
able to keep up with it (I'm not entirely sure that I got your point
there).

Yes, it may not be directly a SCM issue. The history of ruby has been a
history of unmaintained codes. Even today without the chaos of distributed
development, there are many lines of codes in its repo which are not baby-sat.
When you want to increase number of contributions yet decrease number of
unmaintained codes, there should be some mechanism to enforce that. Ruby lacks
that now.

So sorry but I don't like the idea for Ruby to move into a fully
decentralized
development. There should be at least one single center of Ruby as we
have
today. And as a centralized development tool, Subversion is the best
thing we
have.

Excuse my lack of knowledge in this matter, but what prevents ruby-core
from maintaining a canonical Ruby Git repository hosted in the same
servers that SVN resides in right now (or in Github if you don't want to
go through the admin. hassle)?
You can still give commit access only to your list of trusted members
and this "central" repository will be the one that everyone pulls off
when they want to get the official version.
What does SVN gives you that Git misses in this case?

You're saying "there's no reason not to move to git"; but I'm saying "there's
no reason to move to git". Why you hate svn so much? It's perfect for us.

I think a centralized SVN repo + official git-svn mirror is the best
way for
ruby because that should suit for its characteristics and development
style.

I would really appreciate it if you could be more specific in the
"characteristics and development style" that SVN fits so well and that
Git doesn't.

I was pointing to the fact that ruby development is centralized. Centralized
to matz. Have you ever seen a single line email from matz that just says
"commit that please"? Why ruby development do not scale is clear; matz is the
bottleneck. Decentralized development insist him (and us) to grately delegate
what he's doing now to our community. Perhaps that should make YOU happy, but
also make matz unhappy. If you want to hijack his / other committers' power
and authority, you should watch your step not to offend them. To protect their
sanctuary yet to make your path for contribution, a SVN repo + git-svn mirror
is the best way I believe.

=end

[bitsweat (Jeremy Daer)]

=begin
On Fri, Sep 4, 2009 at 2:16 AM, Urabe [e-mail] wrote:

Federico Builes wrote:

Hello Urabe,

On Sep 3, 2009, at 6:44 PM, Urabe Shyouhei wrote:

Ruby is a basic infrastructure that needs to be stable.  If it goes as
agile as
Rails, there should be problems.  A problem may be the hardness for
Rails to
catch-up with Ruby, when both of them are equally as agile.

Is this issue really related to the SCM that the project uses?

Many projects have had an increase in their number of collaborators when
they moved to Git, but that doesn't mean that no one will be in charge
and that it will be moving so fast that projects like Rails won't be
able to keep up with it (I'm not entirely sure that I got your point
there).

Yes, it may not be directly a SCM issue.  The history of ruby has been a
history of unmaintained codes.  Even today without the chaos of distributed
development, there are many lines of codes in its repo which are not baby-sat.
When you want to increase number of contributions yet decrease number of
unmaintained codes, there should be some mechanism to enforce that. Ruby lacks
that now.

So sorry but I don't like the idea for Ruby to move into a fully
decentralized
development.  There should be at least one single center of Ruby as we
have
today.  And as a centralized development tool, Subversion is the best
thing we
have.

Excuse my lack of knowledge in this matter, but what prevents ruby-core
from maintaining a canonical Ruby Git repository hosted in the same
servers that SVN resides in right now (or in Github if you don't want to
go through the admin. hassle)?
You can still give commit access only to your list of trusted members
and this "central" repository will be the one that everyone pulls off
when they want to get the official version.
What does SVN gives you that Git misses in this case?

You're saying "there's no reason not to move to git"; but I'm saying "there's
no reason to move to git".  Why you hate svn so much?  It's perfect for us.

I identify with this sentiment. I resisted moving away from svn too.

It wasn't until a few months of deeply using git that I began to
appreciate how it had changed my development style.

I think the git-svn mirror is a fine bridge. However, I encourage Ruby
core to use the bridge, too, even if just to experiment.

I think a centralized SVN repo + official git-svn mirror is the best
way for
ruby because that should suit for its characteristics and development
style.

I would really appreciate it if you could be more specific in the
"characteristics and development style" that SVN fits so well and that
Git doesn't.

I was pointing to the fact that ruby development is centralized.  Centralized
to matz.  Have you ever seen a single line email from matz that just says
"commit that please"?  Why ruby development do not scale is clear; matz is the
bottleneck.  Decentralized development insist him (and us) to grately delegate
what he's doing now to our community.  Perhaps that should make YOU happy, but
also make matz unhappy.  If you want to hijack his / other committers' power
and authority, you should watch your step not to offend them.  To protect their
sanctuary yet to make your path for contribution, a SVN repo + git-svn mirror
is the best way I believe.

Ultimately, any development workflow may be accommodated, included
protected sanctuaries.

But I think the feeling is clear: no hasty moves for unneeded benefits.

Best,
jeremy

=end

[lchin (Leonard Chin)]

=begin
Below is an edited translation of a conversation about "[Feature
#2033] Move Core Development to Git" on IRCNet's %ruby from Thursday,
September 3rd beteween 10am and 2pm JST. I'm providing this translated
log on behalf of Yugui, and with the permission of the participants.
If nothing else, it will serve as a peek into the opinions of a few
people on the "other side".

== Who ==

• n0kada: aka nobu, Ruby Committer
• unak: aka usa, Ruby Committer (active contributer to the Windows version)
• yugui: Ruby 1.9 Release Manager
• eban: Ruby Committer (active contributer to the Windows version)

== Log ==
unak: [ruby-core:25280] He should have added that "unak doesn't read
English mails"
eban: would anyone actually know who unak is?
unak: true
n0koda: if you checkout win32-unicode-test and still don't know,
there's not much more you can do
unak: I don't think unak appears anywhere in that
n0kada: doesn't it appear in $Author$?
eban: usa
unak: it should be usa
n0kada: so it was usa. whatever
eban: "USA doesn't read English mails." would be surreal

eban: everyone seems to love git
unak: if they want to use git they should just use it
unak: why do they have to force it on other people?
n0kada: just git clone git://github.com/shyouhei/ruby.git
n0kada: and just linking that up with git svn should be enough?
unak: I'm pretty sure there was a clear explanation there too
n0kada: so pasting http://github.com/shyouhei/ruby/tree/trunk on the
ticket should close it?
unak: seems like nobody understands that converting the main
repository to git will only directly affect committers, not
non-committers
unak: 1) if you want to play with ruby's source using git, there are
already git repository (miirrors) so you can just do what you like
with them
unak: 2) it doesn't matter if the main repository is CVS or Subversion
or Git, it has nothing to do with any of you
n0kada: i don't think there was an explanation of git svn there...
unak: http://wiki.github.com/shyouhei/ruby/committerhowto
unak: you mean that link?
n0kada: that's the first time I've seen that
n0kada: I pasted that link and closed the ticket
eban: http://wiki.github.com/shyouhei/ruby/noncommitterhowto
unak: I think you should add it to the top of the (Ruby) wiki, but I
guess its fine just as a ticket

n0kada: runrun just keeps on talking
n0kada: but not with any arguments I haven't seen before
eban: where are you talking?
n0kada: on talk on freenode
unak: what are you talking about?
eban: git probably
n0kada: #2033
unak: why do they keep on trying to force other people to use git?
n0kada: Because for it to be successful there has to be a
snowball effect: a couple of people use it, which encourages more
people to use it, which changes the way in which those people are
organised, which encourages more people to use it, etc. A mirror can
be ignored. I'm not saying it couldn't work, merely that the
commenters in that thread supported moving development to Git; not
just a mirror.
unak: can you summarize it to 3 lines?
n0kada: we want to use it so you guys must use it too
unak: i can't see any explanation for why a mirror isn't sufficient
n0kada: I told him to explain that after reopening the ticket
n0kada: that was my reply to his reason
unak: "a mirror won't work. because it won't work."
unak: thats all he seems to be saying
unak: this is getting annoying. We should just close svn.ruby-lang.org
unak: that's basically the situation he's looking for, right?
n0kada: including the official mirror?
n0kada: now usa proposed to open the official mirror and to
close svn.ruby-lang.org :)
n0kada: :-D Success! :-)
unak: All we need to do now is to get Urabe to say that his mirror is
now "Official" and we're done
unak: So, who exactly benefits from not keeping svn.r.o alive?
n0kada: Who own's http://github.com/ruby ?
n0kada: that would make it look more official
unak: lame
n0kada: No, I mean the feeling of "official/unofficial"
n0kada: i think that's the problem
unak: and I'm saying that the problem of the "feeling" is lame
eban: then you should just state that and we'll be done
n0kada: I think that was the problem from the beginning, is what I'm saling
unak: so why do we have to do this just to make runrun feel better?
unak: if anything, you should be giving more priority to my feelings
n0kada: I'm sure he just wants to feel better without getting in the way
n0kada: It's true that there are lots of tickets that haven't been dealt with
n0kada: On bottleneck is that Urabe's mirror isn't refreshed frequently enough
unak: That's enough. Let's just close svn.r.o and make Urabe's git
mirror official and announce it and get it over with
n0kada: to close svn...
unak: Refresh frequency is only a problem when you can compare it to
commits. If all you can see is the mirror then it shouldn't be a
problem
yugui: I think that git's ability to stimulate community activity is
proven by the example of rails
yugui: So, I guess its fine as long as it doesn't get in the way of
development on svn?
unak: now that there is already a git mirror, I don't understand what
more they could want.
unak: So if the problem is that they can still see the svn repository,
then we should stopping showing it to them
unak: that's just the logical conclusion I arrived at
yugui: I think that what they are asking for is a way for branches
forked from the git mirror to be merged back into a tree for release
yugui: I'm against relying on commercial services like github
unak: but, I guess it should be enough for now
unak: "a way for branches forked from the git mirror to be merged back
in a tree for release"
unak: What ever you use, some kind of tool will be needed for that
yugui: svn's history and merge information is rather weak
yugui: you lose information
yugui: that gets in the way of managing further forks
yugui: I think its those kind of minor details that adversely affect
the activity of the community
unak: that's enough. please, just go and use git
yugui: I think the problem can be solved by using primary git
repository, and making svn a mirror of that
n0kada: what kind of information is lost?
yugui: n0kada: When you merge, information relating to the merge branch is lost
yugui: and if svn is used as the main repository, the hashes change
when you do a git svn dcommit
lchin: yugui: that problem is partially solved from svn 1.5 onwards
with svn:mergeinfo, though its kind of a hack
yugui: After merging a particular branch, merging other forks of that
particular branch becomes difficult
yugui: by difficult, i mean its basically impossible to do so while
keeping git-style history information from the merge point
yugui: I guess you could just rebase, but I think that communication
cost would kill the community
yugui: I just got a similar request from wycats
unak: In exchange I'll die, just hurry up and change over to git
n0kada: will everything be solved by having an svn mirror?
yugui: I think it would be a good idea to keep svn around as a branch
which offers a high probability of leading to a release
n0kada: releasing directly from git would be problematic
yugui: rather than considering svn as "the main place where releases
come from", considering it as "the branch where there is a high
probability of being merged into the master" makes it easier for other
developers to get into the flow of development
yugui: in that case, all the hard work gets left to the release manager
yugui: comitters who want to keep on using svn can keep on using it
n0kada: but if we get bug reports, how do we even know if its the
branch we know about?
n0kada: dying from just the bug tracking workload would suck
yugui: thats why there is a unique hash
yugui: if you can't identify the branch, you can just reject the bug
report and ask for the details of the branch
n0kada: I guess if we ignore versions compiled from git then...
yugui: I see. If we release from git, then people working on platform
dependency issues could have a hard time of it
n0kada: I don't object to having an entry point for git, and a
separate entry point from svn
yugui: how about you, unak?
unak: what?
yugui: are you ok with having both?
unak: whatever is ok
yugui: "whatever is ok" sounds more like a critical response to me
yugui: is that an objection to the proposal to stop using svn?
unak: I'll just fork it
n0kada: from git?
n0kada: [ruby-core:25309] what do they mean by "svn based tools"?
n0kada: i guess they mean tool/
yugui: I think make-snapshot is the only problem
eban: how about the auto-update of version.h
n0kada: i forgot about version.h
unak: personally, i don't care about "official", so you can do what
you want and just not worry about me
n0kada: the snapshot can just continue to be produced from the svn frontend
n0kada: with r12345 and r12346, its easy to see which is newer, but
with abc1234 and abcd4321 hashes, you can't easily tell which is newer
yugui: I think you'll get used to it
n0kada: I don't think I'll suddenly be able to understand raw hashes
yugui: at any rate, not having unak around will be a problem
unak: I'm sure there won't be any problem
unak: thanks to git, the patches will just roll in
yugui: that isn't a fair response. You know that there are lots of
subtleties with OSes that are really tricky to handle well
yugui: especially with windows, people willing to deal with that
platform are few and far between
unak: if its important, then someone will eventually deal with it
right? It's "open source"
n0kada: whatever the backend for svn is, whether fsfs or git or
whatever, I don't care. But I don't see any good reason to throw away
svn.
yugui: I can't deny that small details like revision number are a
pain, just like how having git mirror svn leads to lots of small,
problematic details that raise the bar for participation
yugui: unfamiliarity with git's collection of commands is another
undeniable issue
yugui: Anyway, could you please add a reply to the ticket about the
lack of a reason to get rid of svn?
yugui: the worst thing to have is a communication gap

== END OF TRANSLATION ==

--
Leonard Chin

=end

[jonforums (Jon Forums)]

=begin
On Fri, 4 Sep 2009 07:26:01 +0900
Urabe Shyouhei [e-mail] wrote:

Jon wrote:

Some commiter of Ruby live on Windows.
And windows port of git, msysgit, is still preview (cygwin port is not acceptable).
So we can't move to git.

As a user of msysgit on Win2K, WinXP, and Vista machines I've found the current msysgit preview to be very usable. While I personally prefer Mercurial, I'm quickly becoming a big fan of Git and Github.

That's not the point. The problem on msysGit is that it IS a preview. It's
not a matter of stability. We cannot believe a preview product especially when
that preview software is a fundamental tool to us, such as git.

I strongly agree with your point that a fundamental development tool must be stable for the core committers and their workflows. Quite frankly, anything else is waste of their precious and limited time.

Having trade in your SVN SuperHero utility belt for Git Grasshopper training wheels in the short term really is a developer tax that no one is really eager to pay.

That said, I felt strongly enough that the "preview" label to the current msysgit was incorrect that I came out of "lurk mode" to share my successful experience with msysgit on Windows, and hopefully encourage others to give it a try and decide for themselves. I also have no affiliation with the msysgit project other than a happy user.

One thing that may help minimize the developer tax of learning Git and evaluating whether msysgit in particular will meet the needs of the core developers using Windows, is to add a Committers Workflow Recipes page to your http://wiki.github.com/shyouhei/ruby

Similiar to your http://wiki.github.com/shyouhei/ruby/committerhowto the page would primarily focus on providing Ruby-specific Git workflows that help SVN-based committers quickly get productive with Git. For example, it could be used as a "whiteboard" of sorts in which a committer my post their favorite SVN time-saving trick "How do I do ... in Git?" and others with more Git expertise could answer.

Sure, one can use Google and find a bunch of useful Git tidbits, but having ruby-core Git usage specifics in one place is a value add.

The Committers Workflow Recipes wiki page does not address the perception of msysgit instability, but I think it could dramatically help lower the developer tax of switching to Git for ruby-core specifics. And it should help anyone evaluating msysgit's stability be able to quickly focus on whether msysgit is stable for their particular workflows.

Jon

=end

[takahashim (Masayoshi Takahashi)]

=begin
Hi all,

2009/9/3 Yukihiro Matsumoto [e-mail]:

For various reasons, we cannot move to git at once, so as a small
step, use git://github.com/shyouhei/ruby.git. See

http://wiki.github.com/shyouhei/ruby/committerhowto
http://wiki.github.com/shyouhei/ruby/noncommitterhowto

I like the phrase 'History repeats Itself.'

Subversion is not the first SCM for development of Ruby.
Ruby had used CVS in old days. I guess it is good thing
for us to know (or remember) when and how to move
from CVS to SVN.

On 2005-07-01, about 4 years ago, Shugo suggested to use SVN
as official SCM of Ruby. ([ruby-dev:26421])
At that time, some pros and cons were posted in ML.

1. In SVN, making branch is fast
2. In SVN, making diff to HEAD is fast too
3. WinCVS's graph function is good; TortoiseSVN's one is bad
4. TortoiseSVN in 1.14 is not stable(but 1.2.1 seems stable)
5. In SVN, commit is atomic; its commit log is useful when
   many files are modified.
6. BerkleyDB backend is(was?) not stable. FSFS is stable(?)

We also talked about tools for Windows (as we do now for git).
Some people said TortoiseSVN seemed good but unstable,
and svn commandline client is stable and good for CLI people.

On 2005-07-03, Kouhei Sutou made an experimental repository
of Ruby used by cvs2svn. Some commiters used it and found
some functions of svn was slower than CVS, such as
annotate and log.

But for a while, CVS was continued to use as one true official
SCM tool of Ruby. I could not find the main reason of it.

On 2006-11-28 (more than one year later), usa wrote a summary
of 1.8, 1.9 and moving to SVN ([ruby-dev:29964]).
In the background of this, there was a problem how to merge
YARV into Ruby. Some thought It's the chance to move to SVN.
(cf. [ruby-core:9385])

On 2006-12-20, the mail '[ruby-dev:30039] CVS freeze' was posted
by Shugo. CVS repository was freezed.

On 2006-12-21, the mail '[ruby-dev:30043] SVN ready' was posted
by ko1. SVN repository was ready for use.

Since then, Ruby has used SVN as the official SCM.

That's all.
IMHO, the change of development environment of Ruby is not fast,
but when the chance has come, it happens at the end.
So, if git is better than SVN for Ruby, we will move to git some day.

Thanks,

Masayoshi Takahashi

=end

[hramrach (Michal Suchanek)]

=begin
2009/9/4 masayoshi takahashi [e-mail]:

Hi all,

Hello

IMHO, the change of development environment of Ruby is not fast,
but when the chance has come, it happens at the end.
So, if git is better than SVN for Ruby, we will move to git some day.

At the same time it is necessary to speak about moving to git to get
the lists of pros and cons of the different SCMs as viewed by
different people involved with Ruby in different ways.

Also as a result of this talk we got the git mirror mentioned above
which may not be perfect but is certainly helpful.

Thanks

Michal

=end

[feyeleanor (Eleanor McHugh)]

=begin
The point I suspect that a lot of those pushing for the move to git
are missing is that the current core team are comfortable with SVN.
There has to be a compelling argument for how the change would support
their existing workflow but from what I've read the pressure is mainly
about how git will appeal to a broader community: a community that if
it were really so keen for extending development could already fork
MRI and take the codebase in new directions.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

raise ArgumentError unless @reality.responds_to? :reason

=end

[RickDeNatale (Rick DeNatale)]

=begin
On Fri, Sep 4, 2009 at 3:51 PM, Eleanor
[e-mail] wrote:

The point I suspect that a lot of those pushing for the move to git are
missing is that the current core team are comfortable with SVN.

A very correct point, I'm in complete agreement.

There has to
be a compelling argument for how the change would support their existing
workflow but from what I've read the pressure is mainly about how git will
appeal to a broader community: a community that if it were really so keen
for extending development could already fork MRI and take the codebase in
new directions.

Actually having made the transition between svn (and svk at times) and
git, I'd say one needs to get comfortable with the changes one
must/should make to ones workflow. It's like learning to ride a bike
you need to get the confidence that you can keep your balance.

Git is not just a new svn. Although you can start out using it as if
it were, eventually you'll run into things which will confuse you.
I've run into similar issues as Eric Hodel reported with git, but it's
not that such things are unique to git, I've run into similar things
with svn and other version control systems in the past, it's just that
the way in, and out of those kind of confusing places is different.

On the other hand, in retrospect, I seem to find myself in those
strange places far less frequently with git than with svn. And the
fact that git changes are non-destructive gives me more confidence.

As for being too agile, as others have pointed out git doesn't force a
wild-west approach to the code base. Linux has been using git for
longer than any open source project, and Linus and his committers have
maintained control.

What git does though is allow users of the software to maintain local
patches which are both easy to submit for consideration as part of the
main branch, but also easily keep those patches in sync with the main
branch as it evolves.

I also should say something about the effect that github has had, by
adding 'social' features to git, making it easy for both project
owners and contributors to have visibility to what's happening on a
family of forks, github makes contributing to, and maintaining an open
source project much more pleasant, once you get used to how git and
github work.

My purpose here isn't to push or force anyone to 'move' to git, but I
hope it encourages more experimentation with it as a means of
self-education.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

=end

[jballanc (Joshua Ballanco)]

=begin
On Sep 4, 2009, at 12:51 PM, Eleanor McHugh wrote:

The point I suspect that a lot of those pushing for the move to git
are missing is that the current core team are comfortable with SVN.
There has to be a compelling argument for how the change would
support their existing workflow but from what I've read the pressure
is mainly about how git will appeal to a broader community: a
community that if it were really so keen for extending development
could already fork MRI and take the codebase in new directions.

I just wanted to jump in and point out that this has, in fact, already
been happening. JRuby has Git as its official repo at http://github.com/jruby/jruby
, and MacRuby now has a Git repo that mirrors the core SVN repo at: git://git.macruby.org/macruby/MacRuby.git
(see the message at: http://lists.macosforge.org/pipermail/macruby-devel/2009-August/002261.html
for more information on that).

Cheers,

Josh

=end

[wycats (Yehuda Katz)]

=begin
On Fri, Sep 4, 2009 at 12:51 PM, Eleanor McHugh <
[e-mail]> wrote:

The point I suspect that a lot of those pushing for the move to git are
missing is that the current core team are comfortable with SVN. There has to
be a compelling argument for how the change would support their existing
workflow but from what I've read the pressure is mainly about how git will
appeal to a broader community: a community that if it were really so keen
for extending development could already fork MRI and take the codebase in
new directions.

That has actually already happened with Ruby Enterprise Edition. I do not
consider this a good thing.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

raise ArgumentError unless @reality.responds_to? :reason

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

On Fri, Sep 4, 2009 at 12:51 PM, Eleanor McHugh <[e-mail]> wrote:

The point I suspect that a lot of those pushing for the move to git are missing is that the current core team are comfortable with SVN. There has to be a compelling argument for how the change would support their existing workflow but from what I've read the pressure is mainly about how git will appeal to a broader community: a community that if it were really so keen for extending development could already fork MRI and take the codebase in new directions.

That has actually already happened with Ruby Enterprise Edition. I do not consider this a good thing.

 

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

=end

[brent (Brent Roman)]

=begin

From my recent experiences using a git mirror to manage and merge the MBARI
patches, I can appreciate, and agree completely with, Rick's comments
(below). For anyone used to CVS or SVN, Git brings a steep learning curve.
It's a disruptive "new paradigm" with capabilities as amazing as its cryptic
error messages.

My learning experience was bewildering, but not too terribly frustrating.
The fact is that there are now a lot of good resources on the web to ease
the pain. The only real hacking required in applying my patches to a git
mirror repo was to write a short Ruby script that stripped the SVN key
expansions from them.
Otherwise, strings like $Date$ or $Author$ would prevent patches from
applying as git does not maintain such metadata in source files. Its design
philosophy is to leave source absolutely untouched. This causes real grief
only in the couple places where one sees code like (in runner.rb):

rcsid = %w$Id: runner.rb 11708 2007-02-12 23:01:19Z shyouhei $
Version = rcsid[2].scan(/\d+/).collect!(&method(:Integer)).freeze

After using git, I feel that features like the much touted "rebase" are not
all they were advertised to be. If one has conflicts, rebase won't fix
them. But rebase does automate away much of the tedium of "following the
dancing HEAD" that seems to be associated with getting patches accepted.

For larger patches, following the HEAD can be a real chore. I merged the
MBARI patches with four different Ruby versions. First with the version
1.6.8 (don't laugh :-) we still use in our embedded ARM targets, then with
what I thought was the current production release (1.8.7), then with 1.8.6
(for EngineYard) and finally with 1.8 HEAD for Nobu. Rebase really wasn't
much use for such extensive modifications. By the end of the fourth round,
I was pretty tired. Nobu probably had to do yet another round before he
could apply the subset that he finally accepted into the, by then yet
further evolved, HEAD. The moral is: in the current system, large patch
sets rot quickly and getting them into the core requires dogged
determination. The key crash bug fixes for Continuations were first
submitted to list as patches years before I finally put up my "MBARI
patches" web site.

Right now, the core developers are, understandably, overworked and really
seem to dislike forking the source tree, as they alone are responsible for
its integrity. But, experimental forks are key to testing new features.
This is where a decentralized source management system like git might help:
by encouraging forks and spreading the maintenance load among many more
specialized developers, leaving the core team to focus on new development
and aggregating patches (from forks) already vetted by trusted lieutenants.

• brent

Rick DeNatale wrote:

Actually having made the transition between svn (and svk at times) and
git, I'd say one needs to get comfortable with the changes one
must/should make to ones workflow. It's like learning to ride a bike
you need to get the confidence that you can keep your balance.

Git is not just a new svn. Although you can start out using it as if
it were, eventually you'll run into things which will confuse you.
I've run into similar issues as Eric Hodel reported with git, but it's
not that such things are unique to git, I've run into similar things
with svn and other version control systems in the past, it's just that
the way in, and out of those kind of confusing places is different.

On the other hand, in retrospect, I seem to find myself in those
strange places far less frequently with git than with svn. And the
fact that git changes are non-destructive gives me more confidence.

As for being too agile, as others have pointed out git doesn't force a
wild-west approach to the code base. Linux has been using git for
longer than any open source project, and Linus and his committers have
maintained control.

What git does though is allow users of the software to maintain local
patches which are both easy to submit for consideration as part of the
main branch, but also easily keep those patches in sync with the main
branch as it evolves.

...

--
View this message in context: http://www.nabble.com/-ruby-core%3A25285---Feature--2033--Move-Core-Development-to-Git-tp25262987p25306016.html
Sent from the ruby-core mailing list archive at Nabble.com.

=end

[meta (mathew murphy)]

=begin
On Wed, Sep 2, 2009 at 19:50, Jeremy Kemper [e-mail] wrote:

For decentralized development, cheap, effective branching and merging
is awesome and desperately needed. Git and many other SCMs beat the
pants off Subversion in this respect, and this alone is worth it.

OK, so now explain why Git, and why none of the many other SCMs.

For example, bzr has a much simpler to understand interface than Git, and
unlike Git it has a proper Windows version. It allows decentralized,
disconnected development, and supports easy feature branching.

Bzr also has excellent integration with RedMine, and there's the option of
using LaunchPad if something even more elaborate is needed.

So, why not bzr?

mathew

URL:http://www.pobox.com/~meta/

On Wed, Sep 2, 2009 at 19:50, Jeremy Kemper <[e-mail]> wrote:

For decentralized development, cheap, effective branching and merging

is awesome and desperately needed. Git and many other SCMs beat the

pants off Subversion in this respect, and this alone is worth it.

OK, so now explain why Git, and why none of the many other SCMs.

For example, bzr has a much simpler to understand interface than Git, and unlike Git it has a proper Windows version. It allows decentralized, disconnected development, and supports easy feature branching.


Bzr also has excellent integration with RedMine, and there's the option of using LaunchPad if something even more elaborate is needed.

So, why not bzr?

mathew
--
<URL:http://www.pobox.com/~meta/>

=end

[luislavena (Luis Lavena)]

=begin
On Sat, Sep 5, 2009 at 5:31 PM, [e-mail] wrote:

On Wed, Sep 2, 2009 at 19:50, Jeremy Kemper [e-mail] wrote:

For decentralized development, cheap, effective branching and merging
is awesome and desperately needed. Git and many other SCMs beat the
pants off Subversion in this respect, and this alone is worth it.

OK, so now explain why Git, and why none of the many other SCMs.

For example, bzr has a much simpler to understand interface than Git, and
unlike Git it has a proper Windows version. It allows decentralized,
disconnected development, and supports easy feature branching.

Bzr also has excellent integration with RedMine, and there's the option of
using LaunchPad if something even more elaborate is needed.

So, why not bzr?

Been user of Bazaar for long time, dealing with projects in LaunchPad
and locally at our company.

Pros:

• Able to publish a repository over a dumb protocol make it easy to
  share with others quick code.
• Extensible by plugins

Cons:

• Startup time of Bzr for command line commands is a a killer. To
  solve that you need to use the Bzr shell.
• To switch between branches of a project you need to clone a
  different working copy, unlike Git.
• LaunchPad information and distribution can be overwhelming for newcomers.

During my usage of Bazaar for development of RubyInstaller found a
series of performance penalties when dealing with the checkout tree
generated by all the tools and files the project generates.

After dealing with that slowness, did a test with Git and what is
considered a "preview" version of it for Windows. To my surprise,
performance was great, and scan of changed files, even on huge working
copies ended being even faster than subversion.

Anyhow, just my personal experience.

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

[rue (Eero Saynatkari)]

=begin
Excerpts from Aaron Patterson's message of Sat Sep 05 01:00:11 +0300 2009:

I agree. Git is not a magical potion that makes the patches roll in.

Actually, Git is a magical potion in the sense that a
sufficiently advanced sociology is indistinguishable from
magic.

There is, purely on technical merits, nothing wrong with
using SVN or any other version control system, but moving
to Git would undoubtedly increase interest in contributing
by a significant factor compared to any other solution for
some unknown reason.

One aspect that is not being adequately addressed has been
brought up as sort of a side note: Github. Say of it what
you will, but the current development model of Ruby, from
an outsider's view, is very Web 0.3. Can anyone tell me,
offhand, the sequence of links to click to view the latest
commits to Ruby 1.8.8 in the SVN repository? Add to this
the preceived opacity of the development process, and you
have all the ingredients needed to scare the more timid
among us off.

I personally have no desire whatsoever to be exposed to
the MRI codebase when it is not an absolute necessity,
and the actual benefits of having all kinds of yahoos
writing patches are probably debatable, but accessibility
is currently an issue.

Switching scm's is something for the core team to decide. We should
stop talking about this bike shed and pay more attention to stuff that
matters.

I find "law of triviality" to be a better description than
"bike shedding," especially if it is ANSI-coloured green.

Eero

Magic is insufficiently advanced technology.

=end

[feyeleanor (Eleanor McHugh)]

=begin
On 5 Sep 2009, at 17:03, Eero Saynatkari wrote:

I personally have no desire whatsoever to be exposed to
the MRI codebase when it is not an absolute necessity,
and the actual benefits of having all kinds of yahoos
writing patches are probably debatable, but accessibility
is currently an issue.

Agreed. I've occasionally considered getting involved in core
development but the whole process seems very opaque and as much of my
interest is in low-level uses of Ruby - which necessarily means
forking and extensive hacking - I've allowed myself to be daunted by
the uncertainty of the existing arrangements.

This is less an issue of tools than of social factors, and whilst
moving to git may change some of those it's not guaranteed to make a
difference.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

raise ArgumentError unless @reality.responds_to? :reason

=end

[RickDeNatale (Rick DeNatale)]

=begin
On Sat, Sep 5, 2009 at 4:54 PM, Ron
[e-mail] wrote:

mathew wrote:

OK, so now explain why Git, and why none of the many other SCMs.
For example, bzr has a much simpler to understand interface than Git,

So, why not bzr?

One factor might be whether the software has a critical mass of
users -- both to make sure the software stays around and to have
a good chance community members are familiar with the software.

...

Git (used by Linux, Gnome, Perl, Rails, X.org) or

And LOTs of open-source ruby projects
Many ruby projects formerly on rubyforge or other self hosted svn
repositories are now cloned on github, and in lots of cases the way it
appears to me that's where they are actively maintained.
Rubyforge has provided git as an alternative to svn for some time
now. In the case of my RiCal gem, I have got github and Rubyforge
repositories containing it.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

=end

[RickDeNatale (Rick DeNatale)]

=begin
On Sat, Sep 5, 2009 at 5:39 PM, Jim [e-mail] wrote:

Eric suggested I blog this in case of wider interest.  So, if you are
interested in using p4merge (or perhaps other merge tools) with git, you can
see http://onestepback.org/index.cgi/Tech/Git/UsingP4MergeWithGit.red.

Nice. I'll have to take that for a test drive.

What was the other redeeming aspect?

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

=end

[runpaint (Run Paint Run Run)]

=begin
It would be a real shame if after all this discussion and enthusiasm we just maintained the status quo.

A possible compromise is to incrementally move to Git by splitting the stdlib into one Git repository per library. They could either be periodically merged back into SVN or, ideally, distributed as gems. This would:

• Begin the process of opening up Ruby development by bringing these libraries to the community.
• Encourage new maintainers by establishing a sense of ownership for libraries. This responsibility could be predicated on the creation of a full test suite and documentation.
• Drastically reduce the workload of the core maintainers by freeing them from many bug reports and maintenance headaches.
• Significantly lower the barrier to entry for would-be contributors.
• Reduce the number of people who need SVN access, thus benefiting security.
• Enable the core developers to retain current working practices.
• Free up resources to focus on how the stdlib should change for Ruby 2.
• Leave Ruby leaner.

This wouldn't need to be an all-or-nothing move. Libraries with active maintainers could remain in SVN at their discretion. Nor would it wrest anybody of control. Core developers would have commit access to each component and full control over what gets merged/bundled before a release. They would also exercise control over significant changes to the libraries, should they wish.

This thread shows that their is significant interest in making Ruby's development distributed and open. The Unmaintained Code thread shows that there are volunteer maintainers for want of asking, and that was without any publicity outside of ruby-core. RubyGems, Rake, and MiniTest show the utility of this approach.

There's passion here. Feed it.
=end

[zenspider (Ryan Davis)]

=begin

On Sep 5, 2009, at 17:59 , Run Paint Run Run wrote:

RubyGems, Rake, and MiniTest show the utility of this approach.

I'm really not comfortable with you using one of my projects as
justification for your idea. Especially since I'm completely against
your idea.

I should also point out that rubygems is on subversion and minitest is
on gasp perforce, so they should be considered counterexamples.

Rake is, I believe, officially on git... and yet, it seems to have had
far fewer releases (barring compatibility fix releases) and accepts
far fewer contributions than minitest or rubygems.

There's passion here. Feed it.

We're WAY beyond passion. I don't think it should be fed.

There is nothing stopping you or anyone else from using git to work on
ruby. Indeed, it has been pointed out several times in this thread,
yet that seems to be ignored continuously. There is no reason for you
or anyone else to be pushing git on others.

This zealotry is tiring.

zealot |ˈzelət|
noun
a person who is fanatical and uncompromising in pursuit of their
religious, political, or other ideals.
• ( Zealot) historical a member of an ancient Jewish sect aiming at a
world Jewish theocracy and resisting the Romans until ad 70.
DERIVATIVES
zealotry |-ətrē| noun
ORIGIN mid 16th cent. (in the sense [member of an ancient Jewish
sect] ): viaecclesiastical Latin from Greek zēlōtēs, from zēloun
‘be jealous,’ from zēlos (seezeal ).

THE RIGHT WORD
An enthusiast displays an intense and eager interest in something (: a
sky-diving enthusiast).
A fanatic is not only intense and eager but possibly irrational in his
or her enthusiasm; fanatic suggests extreme devotion and a willingness
to go to any length to maintain or carry out one's beliefs (: a fly-
fishing fanatic who hired a helicopter to reach his favorite stream).
A zealot exhibits not only extreme devotion but vehement activity in
support of a cause or goal (: a feminist zealot who spent most of her
time campaigning for women's rights).
An extremist is a supporter of extreme doctrines or practices,
particularly in a political context (: a paramilitary extremist who
anticipated the overthrow of the government).
But it is the bigot who causes the most trouble, exhibiting obstinate
and often blind devotion to his or her beliefs and opinions. In
contrast to fanatic and zealot, the term bigot implies intolerance and
contempt for those who do not agree (: a bigot who could not accept
his daughter's decision to marry outside her religion).

=end

[Skade (Florian Gilcher)]

=begin

It would be a real shame if after all this discussion and enthusiasm we just maintained the status quo.

Sorry, but long discussions usually show that the proposal didn't find widespread acceptance. I think that it is far more important that this move not be taken lightly.

A possible compromise is to incrementally move to Git by splitting the stdlib into one Git repository
per library. They could either be periodically merged back into SVN or, ideally, distributed as gems.
[...]

Actually, SVN is quite good to manage a standard lib in the style that is present. You can checkout subtrees, etc. All those things are not possible with GIT.

You are proposing a significant change in the way ruby is organized. Someone would have to check for changes in other repositories regularly. Where are those repositories hosted? What if one of them is down? Do rules that apply to ruby trunk/master also apply to their trunk/master? Also, the number of people with indirect, possibly unchecked access to stdlib libraries could rise.

I don't know whether you followed the GHC 'move' to GIT. (Long story short: it didn't really happen) I wouldn't want that in Ruby.

How to you merge history if anyone working on stdlib uses a different VCS?

This wouldn't need to be an all-or-nothing move. Libraries with active maintainers could remain in SVN
at their discretion. Nor would it wrest anybody of control.

This would mean splitting stdlib into (at least) two kinds of libraries that have to be handled differently.

This thread shows that their is significant interest in making Ruby's development distributed and open.

It also shows that there is interest in keeping it under control.

There's passion here. Feed it.

I don't like passion as a technical argument. I for example dislike git. It is a great implementation of a distributed filesystem with no good client, mediocre man pages, arcane behaviour (fast-forwarding branches for example) and far too many ways to shoot yourself in the foot. Feed it.

Actually, I really like the way development on darcs works: Patches are send to a mailing list, reviewed, and potentially merged. There are not a lot of people that are actually allowed to pull patches into main. So the repos is really closed down, but all patches are offical (and can be pulled by anyone).
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Closed

=begin
Closing this issue because it's aged, out of date. Please open another one if you still need it.
=end

[naruse (Yui NARUSE)]

• Related to Misc #10547: How to move the ruby project to git added