[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: merging changes....

From: Greg A. Woods
Subject: Re: merging changes....
Date: Wed, 28 May 2003 13:43:23 -0400 (EDT)

[ On Wednesday, May 28, 2003 at 08:57:59 (-0700), Kaz Kylheku wrote: ]
> Subject: Re: cvs add <directory>
> You want to merge early and often, in the spirit of continuous
> integration.

That depends entirely on the purpose of the branch.  Your example was
almost pathalogical and lacked any useful meaning to a large project.

The only way to take your example into useful form would be if every
programmer effectively worked on their own branch and then a peer review
team did the integration merges to a baseline branch.  The more you do
this though the more you'd appreciate using a two-phase commit system
like Aegis where this style of change management is an inherent part of
the system's design.

> The only reason for not doing so is the psychological barrier created
> by an awkward manual system.

Nope, that's not the problem AT ALL.  NOT ONE BIT.

What people need to learn is the difference between "merging changes"
and the different levels of assistance any one given tool can provide
for merging of changes.  No merge tool can ever guarantee 100% perfect
merges unless it is as smart as the whole programming team combined, as
well as having the specific skills of the compiler parser.

Coding style (code layout, naming conventions, etc.) is by FAR the most
important factor affecting the ease of merging with any tool using
diff/patch to merge changes.

Programmer incompentency is the biggest psychological barrier to
merging.  Anyone hung up on how to use their tools is already heading
down the wrong path and must backtrack to learn the basic skills of how
to copy changes from one place to another and how to resolve inherent
conflicts before they'll ever be able to successfully use any tool to
assist them in making merges easier.

So long as good coding style is enforced for a project any well trained
programmer will be able to select and merge changes with ease even with
the most primitive of tools.  CVS alone can do a wonderful job at making
most merges quite easy to do.  Decent change manifests that suggest the
exact "cvs diff" commands can be constructed and included in commit logs
(using something like commit_prep/log_accum).  Whether "update -j" or
"patch", or Emacs "ediff" is used to do the merging is really irrelevant.

Projects will arrive at specific merging rules that meet the specific
needs of their project.  Whether they maintain a baseline branch, or
not, and whether programmers work on branches, or whether major changes
are made on separate branches, or wether branches will only be used for
maintenance release management, depends entirely on the needs of the

                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]