Re: on reputation and lines and putting things places (Re: gccbranches?)

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

"Joseph S. Myers" wrote:
> 
> On Sun, 8 Dec 2002, Stan Shebs wrote:
> 
> > Now, almost all of *my* merge difficulties have been because Apple
> > changes to GCC are logically contradictory to FSF code.  Does arch
> 
> Similarly, a common occurrence is that a new target, developed for some
> time in an external tree, is merged in, but it follows older coding
> standards and does not take account of global cleanups done to the main
> tree in the mean time.  How could arch tell that, say, FRV's xm-frv.h file
> ought to have been removed when xm-files.h were removed generally from the
> main tree, and the presence of such a file is a conflict, or that a
> particular target macro should have been removed (except that we use
> #pragma GCC poison to ensure that part), or that a certain coding style is
> obsolete, or that all occurrences of a spelling error had been fixed, or
> that something now needs documenting?
> 

If you find something that can really help on these issues, gcc is not
the
only project that has problems like this.  I have used CVS on
applications
that had small teams and still saw global fixes not accounted for when
someone merged their long checked out work.  All it takes is for someone
to
take a significant length of time to work on something while the rest of
the source base moves forward.  

I know that checking for problems like this in submissions to RTEMS is 
tedious and error prone.  I have ot know what version they worked with
and try to account for global changes that might be in the mix.

> --
> Joseph S. Myers
> jsm28@cam.ac.uk

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985