Re: gdb.git mirror is broken

["Joseph S. Myers" <joseph@codesourcery.com>]

On Tue, 6 Oct 2009, Jim Meyering wrote:

> No pressure from me.
> I barely have time to help with the technical side of things,
> so if you want someone willing to invest in advocacy I'm not your man.

I don't want advocacy, but *technical design*.  Technical design based 
around showing how common tasks translate to a proposed new system, 
existing scripts are converted and common errors are made harder.  
Technical design that demonstrates that the usual tasks for people making 
occasional changes are at least as easy and intuitive as now.  Technical 
design that shows how the breakage that is the subject of the present 
thread will not be possible in the proposed system.  (No doubt it will 
also make additional things possible for version control experts, but the 
people proposing designs need to think in normal user terms.)

Personally I think a single repository for GDB and binutils together, with 
configure options for building only one or the other, might be a 
reasonable approach (with other projects left to move from CVS or not at 
their own choice and in their own time), but that's not the level of 
design needed here; it doesn't even address how to handle gdbtk.  For 
shared toplevel files, libiberty etc., I think it would be reasonable to 
do things in a DVCSly pure way and have no master repository and scripts 
automatically merging commits from one repository to another (possibly 
using a different version control system), or to declare GCC the master 
for all files present there and disallow non-automatic commits to the 
shared files on the mainline of other repositories.  But a detailed design 
would need to demonstrate such scripts working in practice.

-- 
Joseph S. Myers
joseph@codesourcery.com