On Friday 09 March 2007 1:07 am, Harri Haataja wrote: > On 26/02/07, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> 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 _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
