Re: merge YARV into Ruby

On Monday 06 November 2006 16:55, Brian Mitchell wrote:
> > The problem is that distributed repositories, by design, are
> > centrally managed.  That is, patches and changes have to go through
...
> 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.

Because that's how decentralized VCS are designed.  By definition, 
*every* check-out of a decentralized is it's own repository.  To 
commit, you have to send patches to be applied to one of them.  The 
fact that it is the "master" repository is entirely a fabrication -- 
there is no master repository, except by convention.  In *most* cases, 
this means you send a patch to a person, via email.  In most cases, you 
*can* set up a repository to automatically accept patches, but this is 
often an add-on ability, and is often accomplished through sendmail.  
In essence, one person has said "I'll accept patches from these people, 
and let software automatically apply them."

This is a conceptual workflow issue, that evinces itself in the 
architecture of the VCS, illustrated by the very fact that very few 
distributed VCSes have native server components.

But, this is really digressing, so this is the last email I'll send on 
this topic.

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

What are you using?  Darcs doesn't do this; bzr doesn't do this... which 
decentralized VCS are you using that has a server process for handling 
pushes?  I'll take my answer off-line -- you can email directly to me, 
if you like.

Darcs depends on an external mail configuration, and has no native 
support for pushes -- it merely applies patches, just as if a human 
were doing it.  There is no native support for push in Darcs, just 
instructions on how to configure a mail server to fool darcs into 
thinking that a person is doing the commit.   That isn't bad, but it is 
a far cry from having push support architected into the software.

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

Yup!  That's what I'm assuming, at least for the moment.

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

Well... subversion doesn't require any administration to make check-outs 
fast.  Darcs does.  A large project with a lot of history can take a 
significant amount of time to check out, unless checkpoints have been 
consistently made, and if the person checking out pays attention to the 
sparsity flags.  Further, if you're doing significant work on a large 
project, including maintenance on branches, you may not have the luxury 
of doing a sparse check-out.

And if you're on Windows, forget it.  You don't get symbolic links, so 
copies (and branches) are expensive.

Again, I love darcs -- I contributed the first XML log patch for it to 
David -- but I don't use it on large projects.  That said, I don't know 
that Ruby is too big for Darcs.

> 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

I *do* need externals.  There are a lot of files in the REXML repository 
that aren't mirrored in the Ruby repository.  I can *not* do this in 
darcs.  It is possible now, with CVS and Subversion (I only check out 
rexml/src into ruby/libs, and use both svn and cvs to keep them in 
sync).  If Ruby is in Subversion, then I'm golden, and my job is much, 
much easier.

> minor annoyance is the lack of a good interactive commit like darcs
> record.

Agreed!  Block level commits.  I wrote a wrapper for subversion (in 
Ruby, of course) once that provided block-level commits for svn, but it 
had a lot of holes -- it didn't deal with properties, and file metadata 
was an utter hack that I never really trusted.

--- SER

Confidentiality Notice
This e-mail (including any attachments) is intended only for the recipients named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please notify the sender of that fact and delete the e-mail from your system.