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

[Rob Landley]

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:

http://groups.google.com/group/linux.kernel/msg/7e7dae0e831d3a88

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
> fork.

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:
http://www.selenic.com/mercurial/wiki/index.cgi/Presentations?action=AttachFile&do=get&target=ols-mercurial.pdf

> 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 
are.)

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...

Rob
-- 
Vista: Windows Millenium Second Edition