Re: New C (and now ObjC) parser, take 4

[Paolo Bonzini <bonzini at gnu dot org>]

> The proper branch model for the new parser is a branch such that every
> file except for a handful just takes the mainline version, with
> mainline changes as they appear, so only changes to files that might
> conflict need merging from mainline to the branch and changes which
> make sense on mainline go on mainline rather than branching any files
> unnecessarily.
> But I don't think CVS can approximate this sort of branching of a few
> files.  (And I don't know if it makes sense in the general theory of
> version control systems, it's just the practical work model that seems
> to make sense for this development.)

This kind of branch does make sense, and indeed CVS does not approximate 
it very well.  I faced a similar problem with my experimental AltiVec 
reimplementation, which probably stalled also because it was in my tree 
only.

A branch is suitable for each and every change for which you need peer 
review and/or incremental development.  Which you are, otherwise you 
would not be sending these messages.

<no-flame-wars-please topic="Versioning systems">
CVS offers a single branch type and, if this is not what you like, well, 
this is a problem with CVS and in general with centralized versioning 
system.

AFAICT, Arch is the only free VS with the powerful branching/merging 
operators.  I am starting to use it for GNU Smalltalk and GNU sed, and 
(apart from being very little user friendly) I am quite satisfied.  But 
I don't see how it can scale to a project with a size and rate of change 
as big as GCC.

The fact that the huge threads on VS ended up in nothing is probably 
because at least CVS sort of works.  The scalability problems in CVS 
only touch those that maintain GCC branches, which is a minority of the 
overall developers, while those in Arch would be more severe.  With as 
many accesses as the gcc repository has, Subversion would take Berkeley 
DB to its limits: and even in smaller projects it exhibits repository 
corruptions which are very bad and (I'm told) not so uncommon.

The two Arch-like VS available are SVK and BitKeeper.  SVK builds on 
Subversion but it is not yet widely used in production.  BitKeeper is of 
course used in production, but as far as possible from being free 
software (as in freedom of course).

These are just quick opinions, others' mileage may vary a lot and I am 
not interested in hearing about that.  I do not want to start another 
huge thread here on VS.  Therefore, I am not going to reply to any 
message quoting the previous four paragraphs.
</no-flame-wars-please>

The problem is, you're not making it feasible for people to review your 
changes.  Your way of conducting development is surely as close pas 
possible to bulletproof, but it may be interesting nevertheless to see 
which bugs you found, etc.

If you do not want to create a branch, please consider *at least* 
putting the full patches somewhere on the web and posting incremental 
differences, instead of sending a 200k message every day.  It is not a 
"take 4" of your C parser, it is the third refinement of the original patch.

But maybe you (or rather the people like me and Geoff that want the 
parser on CVS) can ask the RM or SC about putting it on mainline as a 
technology preview, optionally enabled at configure time like 
--enable-mapped-location.  Since it affects much more existing code than 
the new C++ parser, and given how you are developing it, I guess this 
may make sense.  It would also make it easier for the distro makers to 
test it on Fedora packages, for example.

Paolo