Re: merging changes....

[Sanjay Bhatia]

Hey Greg

I found this message very useful.

Can you point me to some good resources on good programming practices?

Also, you mentioned - 

> 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.

Where can I find out more about Aegis?

Thanks,
sb



 
--- "Greg A. Woods" <address@hidden> wrote:
> [ 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
> project.
> 
> -- 
>                                                               Greg A. Woods
> 
> +1 416 218-0098;            <address@hidden>;          
> <address@hidden>
> Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird
> <address@hidden>
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com