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" <[EMAIL PROTECTED]> 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; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird > <[EMAIL PROTECTED]> > > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
