On 6/16/2010 11:28 PM, Isidor Zeuner wrote:
>> In addition to the effort involved, for very little gain, there's one
>> (additional) problem with switching VCS implementations: we don't
>> provide any *clients* for VCS implementations other than cvs.
> Do you have some background on the "very little gain" assertion? In
> particular, I would be interested in knowing what VCSes you compared
> CVS to, and to what extent.
I've heavily used many VCS's from SCCS to bzr to git and in between. The
only ones I haven't used are hg and darcs. My favorite is actually git.
That having been said...
You have to realize that very little of "MinGW/MSYS" is actually
maintained in our own VCS. MOST of the packages -- like mingw-gcc --
have external repositories, and "our" development happens "there", not
"here". Many are simply shipped just like linux RPMS: we grab the
upstream source tarball, and package that with whatever patches are
needed (think "SRPM")...none of which is maintained in a repo (except,
If you browse thru our repo, most of it is obsolete and unused -- like
all the VERY old "ports" of many msys tools. This switch in
development/delivery practice occurred as we transition from the
"monolithic installer" to "multiple independent packages" model. At
some point, somebody should probably make the effort of deleting all
that now-unused cruft; sigh. As far as current data, it's mostly
the msys runtime source code
some stuff packaged into msysCORE (icons, batch files)
the cross-build scripts
and maybe a few other items. But by FAR the bulk of the MinGW/MSYS
corpus is "maintained" as "here's a tarball including upstream src, some
patches, and a build script".
So...how much benefit will we get by migrating that tiny portion of the
corpus from CVS to anything else?
> True, people are always good at working around tool
> deficiencies. However, it doesn't necessarily mean that not having
> to do so is a disadvantage.
It's a lot of effort to accurately migrate a VCS while preserving
history (anybody can simply import a current snapshot into a brand new
repo of any VCS, of course -- but that's not very helpful). Given the
small amount of the msys project that actually belongs IN the repo at
all, that's a lot of effort to give some users a warm fuzzy when
interacting with that small subset of the full MinGW/MSYS codebase.
Effort that is (a) in short supply, and (b) much better spent working on
stuff outside our VCS, like better mingw-gcc, or a newer port of perl, or...
Wasting time on a email thread haranguing us about policies outside our
control, whose only "acceptable" resolution is to spend man-months of
effort setting up new hosting. man-months we don't have.
> Don't get me wrong, though. I have no objections against a
> pragmatic decision in favour of one option after thinking through the
> alternatives. I'm just opposed to "we always lived in caves, so
> there can't be anything better" logic.
Sure. CVS sucks. Wave a magic wand and instantly convert everything to
git or svn or whatever, with full history support, AND instantly provide
a nice mingw-get-compatible set of packages for msys ports of that VCS
client and all of its depedencies...wonderful.
But I don't have a magic wand.
It comes down to available manpower and time. The core devs are tapped
out; look how long it's taking to get mingw-get out the door -- and even
there, we have a mega-thread from non-core-devs about writing python
scripts to install msys/mingw "in the interim until mingw-get is ready"
-- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity.
So, no, until (a) somebody ports the appropriate VCS clients and
packages them, as described previously, and (b) makes a convincing case
for why the effort of transforming our own VCS repo to $my_favorite_vcs
is beneficial (to the ongoing development of that portion of the corpus
actually IN the VCS) -- it ain't gonna happen. We don't have the time
If that's not the definition of a "pragmatic decision", I don't know