Move part of macports infrastructure to GitHub
Michael Dickens
michaelld at macports.org
Tue Mar 25 07:38:41 PDT 2014
I started my primary devel life using CVS back in 2005 -- before then, I
never really (thought I) needed a repo manager for my code, since it was
pretty much just for me. CVS was fine for what we needed at the time
(3-4 developers, 10 users, 1 leader with commit rights to the trunk /
master), but as the project grew CVS didn't keep up with our needs. So,
we moved to SVN / Trac -- roughly the same as what MacPorts provides,
and I became a MacPorts port developer sometime about the same time as
this move. For how MacPorts works, SVN is fine. For my primary
project, SVN became limiting -- difficult to track branches, do merges,
etc... After some discussion, we set up a copy on github -- and, as the
David pointed out about D, we saw an enormous growth of patch
submissions (primarily via pull requests) and an major uptick in
-useful- discussion on our listserve; users flocked to our project and
it certainly seems like using GIT helped out in that regard (among other
things). Shortly thereafter, we moved entirely to GIT. GIT works much
better for this project than SVN (or CVS) did; we now have ~10 active
developers, and ~50 2nd tier developers (not that this is impossible
with CVS or SVN, but it's just easier overall with GIT). Your repo
manager "goodness" depends on the type of project: for MacPorts, GIT
would work fine but it's a bit overkill. SVN is plenty enough for
MacPorts, and, since it works nicely already, if I had a vote I'd vote
to keep using SVN [note: I've never used hg / Mercurial, but I'm sure
it's similar yet different from/to CVS / SVN / GIT, just with its own
language and twists therein]. That said, I don't really care either; I
am reasonably fluent in SVN and GIT, and I'm sure I could / will learn
HG sooner or later for some project or another. Each package manager
has its pros and cons; just pick your poison and go with it. - MLD
More information about the macports-dev
mailing list