This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin 1.7 release (was Re: The library or libraries will be delivered[...])
Christopher Faylor wrote:
> On Thu, Jun 04, 2009 at 09:40:09PM +0200, Corinna Vinschen wrote:
>> On Jun 4 14:48, Christopher Faylor wrote:
>>> And, also, incidentally, the other thing that is being contemplated is
>>> moving to a more modern SCM like subversion or git.
>> Oh no, not git, please. I'm already fighting against the Samba and
>> syslog-ng repositories with not much success.
>> I still don't understand why everybody is moving away from CVS.
Oh, goody! A religious war! What fun!
I do understand why people want to leave CVS. It has significant
shortcomings (like zero rename support, non-atomic commits, no support
for changesets, etc). But, as you say, it works...and we're all used to
IMO, svn is like cvs with most of the warts knocked off.
>> works and checkin/update are reasonably fast. Seems like other SCMs,
>> especially git, are just en vogue right now. Incidentally, OpenBSD
>> is just creating their own OpenCVS...
The DCVS's are in vogue -- but there is a good reason for that: years of
experimentation on LKML showed that DCVS were stable, didn't encumber
developer's existing workflow, improved collaboration and communication
of patch(sets), and solved the Linus-doesn't-scale problem.
However, very few projects are so active that they *really* suffer from
a Linus-doesn't-scale problem. We may have a Corinna-doesn't-scale
problem -- but that's not related to anything having to do with source
control programs <g>.
There's also the savannah outage last weekend, where a month (well, I
see they later found an uncorrupted backup that was less than a week
old) of commits for hundreds of projects were just lost...
...except for those projects that were using the DCVS repositories. "git
push" from a sufficiently-trusted developer and done.
I kinda like git because of its offline nature: git diff is instant.
Also, I can check-in (to a private branch) locally, without needing (a)
upstream write permission, or (b) to explicitly create my own CVSROOT
and all the management associated with tracking the upstream "vendor
branch" (true, this latter bit *happens* with git -- but it's free; no
additional effort involved).
The downside is that without a good understanding of what's going on
under the hood -- and it IS quite different than us CVS-hounds are used
to -- you can end up doing ugly things to the official repos. Polluting
them with private branches, bad/confusing merge histories, etc. It
takes a lot of care and some actual policy documents to make sure bad
things don't accidentally happen when a developer with push permission
is short on sleep.
But, I'm not picky. CVS. SVN. git. bzr. hg. whatever, so long as it
works. I'll figure out how to use it.
> I suppose we could just stay with CVS while everyone else moves to git.
> If the repository is splitting (which I think it should have done long
> ago) then it won't matter what we use except that updating a single
> sandbox will be a little tricky.
I saw a mention of this splitting you speak of, but not much in the way
of discussion. Is it happening on overseers@ and gcc-steering?