[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] SCMs on Savannah: CVS, SVN, git

From: Mark
Subject: Re: [Tinycc-devel] SCMs on Savannah: CVS, SVN, git
Date: Mon, 26 Feb 2007 09:26:02 -0600

Just a thought: Since you have, I assume, both trees, and DEBUG comes with Windows and DOS, do the following:
[assume file1.x and file2.x]

Click OK
''N'   (for name)
'l'   [ for 'Load']
''d' [ for display]

Gives you a hex and ascii dump of the file, starting at the header.

If they are not the same, conversion is required.

----- Original Message ----- From: "Rob Landley" <address@hidden>
To: <address@hidden>; <address@hidden>
Sent: Sunday, February 25, 2007 7:41 PM
Subject: Re: [Tinycc-devel] SCMs on Savannah: CVS, SVN, git

On Friday 23 February 2007 7:06 pm, David A. Wheeler wrote:
I know Savannah also supports Subversion (SVN), which handles file renames -
though not distributed development.

Can Savannah users commit to the existing tree using SVN, or would it need to
be converted?

I think git is already up and running on Savannah.
There's an hg-to-git converter noted here:

Yeah, there are already some people doing kernel development in hg, git and hg are roughly equivalent tools easy to convert between in both directions. CVS
is to hg what DOS is to Linux: old, crotchety, and full of strange little

There's a Savannah page about Mercurial; all it says is
"Some people would like to see Mercurial support.":

One nice thing about mercurial is that there doesn't have to be one canonical URL to get it from, any more than you need one canonical FTP site to download stuff from. You can have as many mirrors as you like, and keep them updated by whatever means is convenient. (I use rsync between my laptop and my web

I'd be happy to put a mirror of my hg repository up on another site, if that site had hgweb.cgi installed and anybody was interested. Heck, anybody can
set up a mirror of my tree, right now, without me having to do anything.
(When you do an "hg clone" you get a complete local copy of the entire
repository history, you can re-export that just by putting it up on the web somewhere.) That's one of the great things about distributed source control
and open source licenses.  And keeping a mirror in sync is just a cron job
doing an "hg pull -u" (or checking the rss feed, or however fancy you want to

For my Firmware Linux project I already have two copies of the hg repository
on the web, at http://landley.net/hg/firmware and
http://engineering.timesys.com/hg/fwl both of which I upgrade via rsync from
my ~/wwwsend.sh script (because I'm lazy, it was easy to script, and I
already had to set up ssh logins on those servers anyway).

I don't think that will ever get fixed (in the way I think you mean). The
standard solution seems to be "move to SVN or some other system".

CVS was a tool I stopped using in favor of SVN, because the new one could do
things the old one couldn't (such as file renames).  And SVN was a tool I
stopped using in favor of Mercurial again because the new tool could do
things the old one couldn't (such as letting me do a checkin on my laptop
when I'm on the bus, on a 5 hour car trip, or at some place like Starbuck's
or Ikea that doesn't have free wireless internet).

I've been maintaining my own hg fork for several months now, just for my own personal use. I've been collecting other people's patches, merging together clashing chunks, doing a little bit of my own development, fixing bugs I can reproduce, and so on. I've now got over 30 checkins (of varying importance)
that aren't in the savanah cvs.

The tinycc tree is just one of four mercurial trees on my website. I've also got two of my own projects (firmware linux and toybox), plus an old version
of busybox up to when I stopped maintaining it.  I'm using mercurial for
tinycc both because it's easy and because it's what I'm using for everything

When I first started poking at tcc, the repository hadn't been touched in many months and going off in my own corner didn't seem particularly anti-social.
When Fabrice showed back up, I got out of his way:


And prepared broken out patches of everything I'd done to that point:


I then waited several months, and in the absence of renewed work on mainline
(even to the point of catching up to where my tree had been), I started
poking at my tree again.

As for contributing to the official tcc version, "it's an honor to be
nominated" as they say, but it seems the suggestion is that I stop
maintaining my tree and do something else instead:

1) get an account on a system I otherwise don't use, run by an organization whose politics I regularly disagree with, who seem to have set up their own
competitor to sourceforge for purely politicial reasons
(http://lwn.net/Articles/176582/), reasons I've publicly disagreed with in
the past (http://lwn.net/Articles/202106/).

2) switch back to an obsolete repository format using tools that clash badly
with my working style.  (Once you go to distributed version control, going
back to centralized is like using DOS again after a year on Linux.  It's
just...  Ow.)

3) backport six months of work nobody to get right back where my current tree is, after having broken out the patches earlier and posted them to the list,
which got zero interest.

4) Still be the only active committer to said tree on anything like a regular
basis, doing essentially exactly what I was before, only now in a less
pleasant working environment.

This really isn't sounding like my idea of fun. And if it's not fun, given that this is a hobby competing with a half-dozen other major timesinks in my life (including several other software development projects), I'm unlikely to
actually do much of it.

"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery

Tinycc-devel mailing list

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.18.3/699 - Release Date: 2/23/2007 1:26 PM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]