[ 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