On Thursday 19 March 2009 10:30:53 Joshua Phillips wrote: > Rob, > > I feel your pain :( > > I have had a look at the tcc git repository and it has many duplicated > commits (rebased?) and is a complete and utter mess. > > Unfortunately, in my opinion, CVS (and SVN, too, because it is "CVS done > right") are just remote filesystems with an additional rollback feature. > They are not worthy of the title SCM, imo.
Linus Torvalds spends rather a lot of his google tech talk on git explaining why he despises CVS. Personally, I just have trouble _using_ the thing. The main things I use source control are 1) tracking what's changed, 2) tracking down a change (either binary searching for regressions or doing some kind of annotate to find a changeset with associated who did it and why info). CVS doesn't provide changesets. It tracks files individually. You can sort of retrofit the concept of changesets on top of it the way you can shoehorn long filenames on top of FAT's 8.3, but the result is even worse than vfat. (Trying to binary search through these not quite changesets is left as an exercise to the reader.) > I think, if one wants to work on tcc (I don't, right now), one should > completely fork it and ignore CVS and ignore *absolutely everything* to do > with CVS, including other people trying to contribute to the project who > insist on CVS. Seems a waste, but there doesn't seem to be an alternative > :( Been there, done that. > If someone puts your changes into CVS, ignore them. If someone asks you to > pull from a git-cvs mirror, ignore them. Etc. If someone cuts a release from that CVS that has the tinycc.org domain name and gets covered by Linux Weekly News, the majority of which seems to be changes ported from your tree? (I changed the license on my tree to prevent that from happening _again_, but it still meant the semi-dead project had its first release in three years and would take another three years to get as stale again.) Grischka primarily seems to do Windows development, the PE backend. I don't do Windows development, but there's a whole bunch of users there. No matter what the actual compiler part is like, if the other version supports windows and mine doesn't the other one still has a reason to exist and be popular, and that will attract the attention of the Linux community to it. (They may not do much _development_, but their mailing list is the one that'll get the bug reports.) Even when they can't copy my code verbatim, it stimulates them to try, and do so badly. For example, supporting long long constant propogation http://landley.net/hg/tinycc/rev/2768f7c24156 should be ONE code path. If you want to make 64 bit long long support on 32 bit platforms a ./configure option that's one thing, but duplicating a large and complicated code path in the name of "optimization" is STUPID. It was the WRONG APPROACH. Similarly, I implemented -v -v -v to let you see what the compiler's search paths: the #include search path, and the linker search path, and what symbols the linker found while searching. http://landley.net/hg/tinycc/rev/d72f42753974 When tcc copied it, did they realize _why_ I did it? Or did they just export random debug statements that seemed like a good idea at the time with no obvious systematic purpose? (Three guesses.) By the way, did they ever come up with a correct fix to this one? I can't get a log of changesets to see for myself: http://landley.net/hg/tinycc/rev/c8a874736ed2 Has anybody but me ever tried to do any cleanup passes on this code? Things like: http://landley.net/hg/tinycc/rev/d8b3fa09ca5d http://landley.net/hg/tinycc/rev/9414324cc68a http://landley.net/hg/tinycc/rev/1f1a692f7563 http://landley.net/hg/tinycc/rev/7ddeaeed4e94 http://landley.net/hg/tinycc/rev/2d9e5cc32ea9 http://landley.net/hg/tinycc/rev/7fc19a001568 http://landley.net/hg/tinycc/rev/04ef85a39cf4 Yes, I occasionally broke stuff and had to fix it, but you can't grep for anything in tcc! Single character global variable/function names are a BAD THING. It needs to be FIXED. I was doing that, back before the 0.9.24 release rendered anything that _wasn't_ based off the 0.9.24 release (and never would be) obsolete and unofficial. Let alone breaking out option parsing into a separate file, moving the code generators into per-target subdirectories, creating tcc.h in the first place... Nobody's doing infrastructure work on this thing. Nobody's trying to build real packages with it and fixing the bugs. Nobody's filling in the missing C99 features like variable sized arrays. Nobody's worried about powerpc or mips support, or trying to come up with a libtcc.a for arm. (Lots of code refactoring to make multiple backends easy to do systematically. Notice how I was doing lots of code refactoring?) It's similar to the code refactoring to make tcc produce ld and strip and as commands in multicall binary fashion ala busybox. I suggested that would be a good idea what, a year ago? I'm fairly certain this wasn't the first time: http://www.mail-archive.com/[email protected]/msg01861.html Anybody shown any interest in doing it? Of course not. Current manpower of tcc is pretty much zero, but they have to deal with manpower before dealing with the source control, when the source control is driving away people like _me_ would would otherwise work on the project. Go ahead, put the cart before the horse why don'tcha. If you had to subscribe to a usenet newsgroup to follow development (in 2009), you'd understand that it would drive away developers. Mailing lists are the way we do it now. If all the project's filenames had to fit in DOS 8.3, you'd understand it would drive away developers. But requiring the use of a source control system from the same era is NOT viewed as driving away developers. Sigh... > I don't know whether tcc is half dead because of the CVS analness > (is "analness" a real word? :) or vice versa, or just lack of interest. > Maybe it can pick up a bit of momentum if it's managed by an SCM. When I started my fork, tcc was already essentially dead. The _existence_ of my fork seemed to revitalize it. I'd work on my fork, work on the rest of tcc would pick up again. I'd stop work on my fork to get out of its way (the first time sending a tarball of accumulated patches to Fabrice), and tcc would grind to a halt again. So I'd start work over in mercurial again, and CVS would start moving again. I did this what, five times? Got sick of it. I don't want to fight another project. I _want_ to participate in a multi- developer project. But CVS remains a deal breaker. This project has proven it would rather die than switch off of CVS. I just check back every 6 months to see if it's changed its mind. > Anyway, just to say I agree, really. Thanks. People keep emailing me to say they agree, but nobody ever seems to post to the list to say they agree. And thus nothing here changes, but if somebody starts something _external_ its brains get eaten by the zombie CVS. Rob _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
