Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Anthony Foiani (tkil_at_[hidden])
Date: 2011-01-29 03:07:31

Ted, all: greetings --

"Ted Byers" <r.ted.byers_at_[hidden]> writes:
> Really?  Anyone with any experience has faced this sort of thing
> countless times before, and even in the absense of software that
> makes handling this easy, have developed methods (often manual) to
> deal with it.

This is a key observation.

Having said that, would rather have generation after generation of
"complete novice" programmers have to climb this wall -- each in their
own way, with their own tools, using their own toolset, and their own
assumptions -- or would you prefer to switch to a tool that solves the
problem for you (and them)?

You're completely correct that it's quite trivial to generate local,
offline snapshots of an SVN tree.  Here's mine:

  $ cat snapshot-dir.sh 
  #!/bin/bash
  #
  # snapshot-dir.sh
  #
  # This is mostly useful when we can't get to a version control server,
  # but still want to capture a particular edit state.  Switching to git
  # (which is local by design) is probably really the right answer, but
  # for now...

  ts=$(date +'%Y%m%d%H%M%S')

  for d in $*
  do
      echo "=== $d ==="
      tar --create \
          --gzip \
          --verbose \
          --file "saved-snaps/$d-$ts.tar.gz" \
          --exclude ".svn" \
          "$d"
  done

But you know what?  Integrating those local snapshots, once I was back
on the network, was quite a bit more effort than I'd like.  The
difference between a home-brew snapshot script (and manual merging),
and a tool that is designed to support this style of work, is huge.

Would you rather your programmers spend time writing tools like this,
or would you prefer they utilize toolkits that give them the features
they need up-front?

> But then, in a commercial setting, part of the role of the senior
> programmers/team leads/&c. is to teach their juniors so that they
> are flexible enough to cope with these situations regardless of the
> supporting software used.

Another role of the "senior programmers", however, is to step back and
review their *process* occasionally.

That's a big part of what this thread is about; the contributors to
boost are by no means "novice" programmers.

> What I encourage among my team is to never throw anything away,
> unless it is demonstrably wrong.  So, even with something as
> primitive as RCS, I/we wold not be "hosed".  If git provides help
> with this, fine, but it is not essential.

How do they "never throw anything away"?  How are those changes
tracked, and do they have contemporaneous comments that would make
suitable commit logs?

Put another way, how many possibly-useful changes are sitting in your
developers' working directories, under names like "third-try" and
"oops"?

> Please understand, I am not arguing the merits of git with you.
> Rather, I am pointing out you haven't made the case that a change to
> use it instead of SVN is either warranted or feasible or
> practicable.

Totally agreed.

In this case, I would venture that there are some non-arguable facts:

1. Boost development is decentralized.

   This seems obvious on the surface.  Multiple companies,
   programmers, countries, and even timezones.

2. Boost release coordination is centralized.

   This is a good thing!  There is one focus for naming, QA, praise,
   and complaints.

3. Any DVCS can trivially emulate any given centralized VCS.

4. The DVCSs under discussion (hg and git) have both been proven
   workable (and, in general, superior to centralized VCSs and simple
   email patch-passing) by some very large, very popular, and
   many-contributor projects.

> I have a number of products in svn, and if I am to be convinced to
> use any other version control software to manage their code instead
> of SVN, I'd need to be presented with an analysis not only of what
> each option (RCS,CVS,SVN,git,MKS, &c.) offers, but proof that each
> works as described, that the benefits of making a switch outweigh
> the costs, and a viable plan for making the switch.

This is a laudable goal, but proper "proof" consists of running both
scenarios in parallel (providing a control group).  Boost being a
volunteer effort, I posit that it is impossible to "prove" that a
particular change in methodology yields a specified cost/benefit
ratio.

Lacking rigorous proof, we can instead look to the experiences of
similar projects.  Of those projects that are large and decentralized,
it seems that the choice to use a DVCS has been largely accepted.

I would suggest following their lead.

Best regards,
Tony