This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc development schedule [Re: sharing libcpp between GDB and GCC]


On 26-Mar-2002, Tom Lord <lord@emf.net> wrote:
> Regarding revision control, there can be a queue from branches
> (including branches outside the main repository) to the trunk.  For
> most change sets, propagation along that queue, passing through the
> testing barrier, can be automated.

Resolving merge conflicts can never be automated.

> >  	In addition, it assumes there is no overhead associated with
> >	maintaining a branch
> >     Sorry, but nobody is going to merge a complete rewrite of the
> >     C++ parser, for instance, to the head, without *any*
> >     difficulties whatsover.
> 
> Using _any_ modern system, the merge can be worked out on a branch and
> the transition to the trunk automated.

That doesn't solve the problem.  If changes stay on branches for longer,
rather than being incorporated in the trunk, there will be more conflicts.
This leads to increased overhead resolving the merge conflicts.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]