Re: merge YARV into Ruby

On Monday 06 November 2006 13:37, Kirill Shutemov wrote:
> On 11/6/06, Sean Russell <[e-mail]> wrote:
> > 1) Sylvain is right about the development model of Ruby being more
> > in-line with having a central repository.
>
> Do you think that distributed repository will not be useful for
> adding new libs to standart library or make a global redesign in ruby
> core? I think it's very similar to kernel development process(adding
> new drivers and changing internal interfaces).

The problem is that distributed repositories, by design, are centrally 
managed.  That is, patches and changes have to go through one person -- 
one person owns the repository.  Centralized repositories, by design, 
expect that contributors all check in independently, without one 
central authority proofing every commit.  Linus ultimately oversees and 
approves every patch that goes in.  Recently, he delegates the actual 
patch proofing to lieutenants, but he still performs the commit 
himself.  Matz does not work this way.

Now, you can set up distributed repositories to allow all contributors 
to check-in without oversight, but that's the exception, not the rule.  
And you can set up centralized repositories to require confirmation by 
an individual before the commit is excepted -- again, the exception, 
not the rule.

Ruby is not developed like Linux is developed.  At least, the standard 
libraries aren't, and this lends itself more to a centralized 
repository.

Don't get me wrong: I like distributed VCSes, and I think that they're 
useful.  I waffle between SVN and Darcs; they each have really nice 
features.  However, I think that, in the case of Ruby, a centralized 
repository is a better architecture for the current development model, 
and the paradigms and workflow of SVN, being nearly identical to CVS, 
is a logical choice for a project that has always lived in CVS.  
Finally, I've found SVN to be extremely scalable and robust; as much as 
I like some Darcs features, I'd be reluctant to use it on a large 
project.  I can't speak for Monotone, bzr, or git (which has obviously 
proven itself on large projects).

> Git allow it by design, but I don't know if such merge-strategy
> implemented.

Git supports externals?  That's a surprise to me.  Some day, I need to 
build a matrix of common workflow tasks and see how the support in each 
VCS stacks up.  For example, checking in and out are pretty standard 
tasks, but I also find that there is a set of other features which is 
just painful to do without:

	Who changed what line of a file last (svn blame, cvs annotate)
	List all files changed in a commit (svn log -v)
	Shelving (svn cp; svn switch; svn ci; svn switch back)
	View all changes in a commit (svn diff -r V1:V2)
	Branch/tag a given revision (svn cp)

What I miss most from Subversion is block-level commits.  Oh, there is a 
feature of distributed VCSes that I sometimes miss: the ability to 
cherry pick features from several forks of a projects.  I think this is 
a really underused feature, but it doesn't work well if there isn't 
good patch theory support, and I really don't think it would be any 
benefit at all to Ruby.

--- SER