[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] SCMs on Savannah: CVS, SVN, git
Re: [Tinycc-devel] SCMs on Savannah: CVS, SVN, git
Fri, 9 Mar 2007 14:56:15 -0500
On Friday 09 March 2007 1:07 am, Harri Haataja wrote:
> On 26/02/07, address@hidden
> <address@hidden> wrote:
> > Rob, I appreciate the work you've done and encourage you continue in
> > whatever environment is most productive for you.
> Distributed source control is indeed one of those steps where you'll
> never want to go back. Personally I much prefer darcs, but agree on
> letting people who will really use the tools pick the tools. It's a
> shame if there's an organization limiting the use of something.
I haven't got anything against darcs, I've just never tried it. I know that
tailor's associated with the darcs project and it's what I use to convert svn
and cvs repositories to mercurial.
In theory, with distributed source control systems you can have transparent
lossless conversion between them all, so hg can pull from git and vice versa.
This doesn't use tailor, this uses explort plugins to git and hg. I haven't
personally tried it, I just know there are kernel developers doing their work
in mercurial, and Linus is pulling from them in git:
Dunno if darcs is in on the party yet.
> Apart from browsing the source and versions (patches) via cgi's, darcs
> at least shouldn't require any server support, I think.
Same with mercurial.
If you want to put an hg repository on the web, all you have to do is copy
the .hg directory and its contents onto the appropriate web page, and then
use "hg co static-http://blah/blah" on the directory it's in. (This is
slower and doesn't give you the nice web gui thing if you point your browser
at that directory, but it works fine and was what I did before I bothered to
set up the cgi.)
> I don't know
> about the others. If you have a copy of the repository, you have a
> working fork and you can generate patches that can be fed to another
Yup. And the point of distributed source control is that the forks can come
back together (merge) which is how you get loops in your revision history.
(And why you can't always say "is checkin h before checkin j? They were done
in parallel in different trees and it didn't get merged back together until
checkin q. Both were before q, and both were after c, but neither is before
the other, they're off ot the side.)
At which point you start drawing diagrams, ala page 33 of Matt Mackall's 2006
OLS slideshow from his presentation on mercurial:
> I wish someone continues to make tcc useful. I would very much like to
> see it in many places. There aren't that many alternatives for C
> compilers and gcc (and esp glibc) are humongous. If only some
> simplicity and cleanness can be maintained. If the idea is to start
> expanding tcc, maybe it would be better off forked to keep the "tiny"
> branch and a more full featured different approach separate.
Nah, it doesn't need to be forked. It just needs to be cleaned up so it's
more modular and you can pick and choose which modules you're interested in.
(Preferably without having to spend 6 months first learning what your options
However, I'm not going to fight Fabrice over the direction of the project. I
spent a large chunk of last week figuring out why gcc 4.x broke soft float on
arm, and when I get back to that I need to figure out how to add the right
#ifdef guards to the patch I found that currently fixes the --disable-shared
case but breaks the --enable-shared case. This past weekend I was out of
town. Monday and tuesday I was getting out the 0.2.0 release of Firmware
Linux. Tuesday and wednesday I was adding the start of powerpc support and
debugging uClibc issues. Thursday I was on a conference call with my manager
and somebody from codesourcery talking about qemu, which resulted in me
writing documentation (part one of three).
Today I'm trying to catch up on some mailing lists, debug a blocking uClibc
issue on powerpc, clean up my gene2fs thing in toybox so it least compiles
again (so it stops blocking putting mdev into there so I can update mdev to
work with the 2.6.20 kernel which now has symlinks instead of subdirectories
under /sys/class and thus needs different traversal logic (and yet naieve
recursion will still result in an infinite loop, thanks Greg KH)), and if I
have time I should probably figure out why sparc is hanging and maybe finish
up the soft-float thing before doing the 0.2.1 release of FWL, and _then_ I
get to tackle either distcc or putting together an build environment in which
to run gentoo's portage, from scratch. (Stage 0->stage 1 when I can't even
find documentation telling me the differences between stages 1, 2, and 3
anymore. It all bitrotted.) I didn't get to write a CELF presentation
proposal (and only one for OLS) this year because I was too busy. I really
shouldn't be spending time writing this email. :)
I'm still interested in tcc, but it's quite easy for me to let it sit another
three months. Pretty much the default case if I don't go out of my way to
make time for it, actually...
Vista: Windows Millenium Second Edition