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

On 11/6/06, Sean Russell <sergermane-software.com>
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.

For centralized development, I'd pick SVN.

For distributed development, last time I evaluated options I
decided
I'd pick Monotone, which I haven't seen anyone mention yet.
<URL:http://venge.net/monot
one/>
It runs on Windows, Linux and OS X.

I tried Arch. Horrible, horrible UI, broken handling of
filenames.
I didn't try Darcs because Haskell is too obscure and
non-portable.

I'd certainly look at bzr and Mercurial if I wanted to
change SCM
system again, but when I last had to change they were too
immature for
serious use.

SVN certainly has the advantage that there are lots of tools
to
support it, including plugins for Eclipse and the OS X
developer
tools, and UIs for Windows, GNOME and KDE.


mathew

mathew <metapobox.com> writes:

> I didn't try Darcs because Haskell is too obscure and
non-portable.

Which platform are you missing?

  ht
tp://hackage.haskell.org/trac/ghc/wiki/Platforms

It's not like you have to build it yourself, even...

  http:
//www.darcs.net/DarcsWiki/CategoryBinaries

-- 
Christian Neukirchen  <chneukirchengmail.com>  http://chneukirchen.org