[OT] Casual discussion of SCM (was: merge YARV into Ruby)

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

And that is why it is so great! Notice that we just "fabricate" the
master repository out of thin air. The "add-on" you call is push
capability. It is rather standard with good sscm systems these days
(mercurial, darcs, svk, git). There is no illusive person there. Just
a protocol. The same goes for svn. You have to setup a central server
to accept commits. It just happens that most things require that setup
in svn while dscm tools don't.

In other words, dscm's are flexible.

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

I have exactly the same work flow minus one thing: I commit much more
often to maintain easier to manage and more descriptive changes when
using dscm tools. This is because I don't need to worry about breaking
the repo for someone else  while I work on new code. I can write tests
and commit and then write code and commit. Once I feel the changes are
ready to push I will push them or provide a place where people can
pull from. This difference makes ideas like a master repo much more
manageable and the change-log much more coherent.

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

I am sometimes bugged by the extra noise but I do believe that
Rubyists tend to enjoy good conversation. I feel that this thread has
maintained itself as a good conversation. Maybe a little bit of debate
but we are all level headed people who know how to use mail clients
effectively. The main problem is the fact this has derailed the
original thread. I've changed the topic now to reflect that.

> > 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. I either give an HTTP capable location (not hard at all) or SSH
location of the repo. When I want to push to it I use SSH or send mail
to the appropriate address. Two very simple options. On a few
occasions I might pull to the master repos but I can't think of a time
in the past month that I did that.

bzr is mostly broken as far as I am concerned. I don't want to make
people mad but it's feature set is really off balance. I hope the best
for the future development of that project but I have never seen a
unique and positive reason to use bzr. I would love to learn more
about why some people like it so much though. There has to be a reason
it is being wiritten, no?

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

It does not really depend on it. Only if you want to send patches via
mail. I don't know what you mean by lack of native push support if I
can use the darcs command called push to do exactly what it sounds
like it needs. Darcs supports the following mediums, which you are
probably aware of:

Filesystem (push/put and pull/get)
HTTP (pull/get)
SSH (push/put and pull/get)
Email (send -- like a push)

In some of these cases a binary on the "remote" side will kick in but
this isn't hard to setup (just put an executable in $PATH -- compared
to svn and possibly apache ;-)).

I bet you could add more if you felt the need. The project is pretty
open to contribution. I would love to see support for more isolated
pushes that don't use signed mail. SSH gets close but requires that
you lock down whatever account is used.

> > 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 am always into change. What I do today with darcs hopefully isn't
the end of all solutions. I look forward to the day where new ideas
empower new tools. That is why I picked up Ruby years ago. I don't
claim that all people should be this way but it sure doesn't hurt as
bad as some think it does.

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

In my case, svn takes about the same or longer time to check in large
trees and can be even slower when tailoring histories to it. This is
from real code in real projects. They scale from large apps to small
ones. Maybe my svn repo needs a better setup but I always wait less
time with darcs for gets, puts, inits, records, pulls, and pushes.
Maybe it is an illusion though. I have no numbers to give right now.
Both seem fast enough when it comes down to it. I just don't buy the
slow-darcs argument anymore. (Yes, checkpoints rock. They are useful
for more than fast performance -- think of storage space and bandwidth
usage)

> 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've got disc space. For those who don't, check out mercurial which
does an excellent job if you are using NTFS. It is a valid complaint.
Maybe someone who uses windows should contribute support for it (I
rarely use windows these days). Though I should still stress that ruby
shouldn't use darcs until darcs supports more platforms so developers
don't have to juggle source around in those cases.

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

Interesting. Maybe they should be added to darcs. I know some people
have avoided that feature because you can easily script it in. Notice
what the GHC darcs repository does. It is a simple yet elegant
solution to externals. It seems more proper in a way but I haven't
thought about it much. I would love to hear more about this.

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

Sounds interesting. I would love to see the script sometime if you
don't mind. I still have to live with svn in a few cases and that
would make my life easier. With or without holes, I'm sure it could be
cleaned up if enough people were interested in it.

Cheers,
Brian.