On 5/4/10 1:14 AM, James E Keenan wrote:
Friends,
My name and nick were invoked recently on #parrot as part of the VCS
wars. Since $job usually precludes my attendance at #parrotsketch, let
me state my position here.
Thanks for this Jim. I hope you didn't feel too much like a
poster-child. :) I really do feel substantially more comfortable with
git knowing you're comfortable with it. The same is true for Coke, who
was hesitant about git a year or so ago, but is now in favor.
I would like to hear from anyone who has reservations about a move to
git. This is a serious decision, not to be taken lightly. With code
changes we can rollback a bad commit or branch merge. Infrastructure
changes are riskier. We planned for *six months* for the move from
perl.org to parrot.org, even though it was only a change of servers
using the same tools. It was mostly smooth, but we still didn't get it
all right (see Patrick's comments on Rakudo not getting enough notice).
(d) VCSes come in and out of fashion and tend to spark passionate --
even hyperbolic -- arguments on the part of their adherents. IIRC, at
YAPC in 2001, everyone was raving about darcs. By 2004, Subversion was
in. By 2006, the cool kids were using SVK on top of Subversion. And by
2008, the same people who were raving about SVK had moved on to git. And
my impression is that -- perhaps inspired by Linus Torvald's notorious
talk at Google -- git advocates are more prone than others to scoff (or
worse) at those who disagree with them.
I've noticed this. I apologize to anyone who feels like I haven't been
listening to them. I'm really trying, but my reaction to this kind of
enthusiasm is generally to discount what the person is saying because it
isn't cool, hard logic.
(e) If there is a dispute over an open source project's policies and
practices, the burden of proof falls on those in the project who wish to
change those policies or practices. The rationale for change and its
supporting evidence should be presented in a more or less structured way
on the project's mailing list or in some other appropriate forum. Simply
sounding off on IRC about how you could be so vastly more productive you
could be if only the project changed policy X is insufficient. The more
you whine about a project's policies on IRC, the less I am impressed
with your argument.
So far, the compelling reason I've been given for why we should move to
git is branch merging. But, it's been demonstrated quite effectively
that the git merging tools work on an svn data-store.
I totally understand that some people prefer working in git, and as far
as I know most of them already are (pulling from the svn central
data-store). What I don't understand is what advantage we gain from
using git as the central data-store. As far as I can tell, in the age of
distributed version control the format of the central data-store is
entirely irrelevant. (At if it really is irrelevant, the weight is on
keeping what you already have because of the cost of migration.)
(a) Questions needing discussion:
(i) What are the strengths and weaknesses of both centralized and
distributed VCSes? Should Parrot move away from a strictly centralized
VCS? If so, given that distributed systems can be set up with
quasi-centralized repositories (this is what's happening at $job), how
decentralized should our distributed VCS be?
The funny thing is, AFAIK no one whats to switch to distributed
development patterns. The git advocates want to use git as a centralized
repository. If we were planning to move to a more distributed
development pattern, I would consider git a greater advantage.
(ii) There are at least three distributed VCSes that, on the basis of
their adoption by other large, open-source projects, deserve our
attention: git, mercurial and bazaar. What are the strengths and
weaknesses of each? Are there people we can speak with who have
extensive experience with two or more of these?
I consider all three equally good. Well, of the three I actually have a
personal preference for bazaar, but they are technically equivalent.
(iii) If we do decide to move to a distributed VCS and settle on a
particular VCS, what shall our migration plan be? (Note: On the basis of
my past and current experiences, this is the issue that needs the most
discussion but will likely get the least.)
This I would like to see a great deal more on. About the only way I'm
likely to be comfortable with a move to git is if we do an entire mock
run on the migration to a test server, including the
svn-dump-and-git-import, the integration with Trac, email notifications,
and our tools for access control management. We need to figure out
hosting, if our current hosting can support git, if we'd use a service
like githib. We need to figure out if Trac integration will work if git
is hosted on a different box (svn and Trac have to be hosted on the same
server for the integration to work). I want to know if we can do bzr and
svn mirrors from git.
I also want to see the equivalent of our
docs/project/committer_guide.pod written for git. I want to see
agreement among the git users on a project standard for how we setup our
local repos, how we do checkouts, commits, branches, merges, where we
publish our private branches, etc. I know git allows for dozens of
different styles of development, but it makes it enormously difficult to
collaborate with other developers when you have to work around a dozen
different ways of doing things (I've already been bitten by it, and
we're not even using git all that heavily at the moment.) I want a plan
for how we'll refer to revisions, and if there is a good way to save
existing references to our 46286 (and counting) revisions, a policy on
how we'll tag releases, and details on how we'll restrict our git
hosting to prevent the more destructive repository-changing commits that
git allows.
Ideally, I'd like to spend some time talking to a sysadmin who has done
svn migrations and maintains git repos. Specifically, one who is willing
and open to talk about the disadvantages of git as well as advantages.
(All software has disadvantages. I worked as a sysadmin for years, and I
don't believe anyone who tells me a particular package has none.) These
kind of infrastructure decisions are trade-offs, working out if the mix
of advantages/disadvantages of one system are a better fit for the
particular project's needs than the advantages/disadvantages of another
system.
(b) Venues for discussion:
(i) As suggested above, I don't think IRC is a satisfactory venue for
this discussion. In fact, I'm going to state right now that between now
and YAPC I'm not going to pay attention to anything whatsoever said on
#parrot concerning Parrot's VCS choices.
Unfortunately, I won't be at YAPC::NA. Whatever parrot devs are there
can certainly get together, but it wouldn't be effective at resolving
this conversation.
I also get the impression that the git advocates would like an answer
soon, so the end of June may be too long anyway.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
