Re: merge YARV into Ruby

On 11/6/06, Sean Russell <[e-mail]> wrote:
> 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.

I don't know where you got that. I use distributed version control
systems every day that allow people to check in changes independently
of me or anyone else's overview.

> 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.

Really? I don't get where you are coming from again. I usually just
tell my co-workers: Ok. My new library is available at x/y/z. And it
is ready to go. They just need the path and that is it. Not any more
than svn or other centralized systems need. This is a side effect of
supporting both full push _and_ pull (which not all dscm's support --
cough bzr [0]).

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

Well, lets not put too many stops into "how" anything is developed.
Ruby has been using CVS for a long time which has pretty much governed
how things are to be managed. There isn't much room to change with
CVS. I'm not saying it was bad. I'm saying that you are supposing that
Ruby's development process will stay the same.

In these cases, I would delegate to Matz for final decision. It seems
he has already done an evaluation of many of these options [1]. Not
really sure what his final conclusion was though.

> 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).

I agree enough with some of that though I wouldn't say Darcs doesn't
scale well (in comparison to svn) at this point. I use both svn and
darcs every day and darcs consistently outperforms svn on most
operations. Add in some hooks to auto-push and pull stuff from
different locations and it pretty much acts like svn as well.

I should note that I would not recommend darcs for Ruby development
for only one reason: darcs does not run on all the platforms ruby runs
on. Mercurial is the closest dscm to darcs that will also run almost
anywhere. I've actually thought of porting it to ruby on more than one
occasion [2]. :-)

> > 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.

I agree, though I don't think we really need externals in this case (I
call scope creep) Cherry picking is a big one on my list. Another
minor annoyance is the lack of a good interactive commit like darcs
record.

As much as I would _love_ to see a distributed scm used I think I
would also be fine with the "good enough" solution that Subversion
provides. Maybe a little bit of automation with the tailor tool would
make more people happy. I know I do it already for projects like rails
(very handy to have my own small changes trackable for production
systems).

Brian.

[0] I think there push support in progress but I still find the usage
of bzr to be too complex for its own good.

[1] Search his blog entries at www.rubyist.net/~matz

[2] I really don't have the time right now though.