Re: [Tinycc-devel] Is the CVS repository dead yet?

[Rob Landley]

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/address@hidden/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