Hello Edward,
On Mon, Jun 10, 2002 at 07:42:37PM -0500, Edward Dunkle wrote: > please excuse if this is a double post. It seems earlier posts have failed. > > What is the recommneded practise for building an incremental release without > pulling in incomplete code changes in the main trunk? > > Some have suggested that we never branch and merge but simply tag individual > files associated with each implemented change to be included in the next > release so that each of these may be pulled specifically. Do you see any > issues with this approach? > > The docs seem to describe branching and merging as an approach to use. Are > people successful with this? > > DO you make releases off a branch and then merge it into the trunk and then > make another branch for the next release? > > Do you make one branch for each release or branch and merge for each change > request that is to be included in the next release? Personally, I branch for releases. Changes that are applicable to both the branch and trunk are checked into the trunk and moved to the branch by the build/release engineer (me), and changes that are only applicable to the branch are made directly to the branch. I think that merging is great, but I don't think it's ok to do blind merges back and forth without making sure the code is still doing what you want it to do. Especially when you get into conflict situations. If there have been tons of system-wide changes on the trunk, you need to intelligently remove things on the branch and move them from the trunk. This is usually the kind of situation you want to do a new release for, not really a "patch". If it's just a "patch" release for a bugfix, then it's pretty easy to move individual files from the trunk to the branch by hand, or make changes directly to the branch if the patch is no longer applicable to the trunk. I usually don't merge between the trunk and the branch, just copy. This is just a personal preference, I think copying is easier, and keeps the trunk and branch versions in closer sync, and makes it easier when looking at version history to see what happened ( rather than two checkin comments that say "fixed rollover bug" in two different ways, you see one "fixed rollover bug" on the trunk and "copied rollover bug from r1.4 from the trunk" on the branch revision ). Again, personal preference. This depends alot on your product and your release cycle, of course. I usually look at releases as "frozen", you only want to update a branch in order to fix bugs. If you *need* to add a feature to both the release and the current development ( which I discourage ), or fix a very deep bug, it is done as above, carefully by someone who has some understanding of what they are doing, and access to the developers who made the original change ( or maybe by the developers themselves ). I don't see any reason to ever merge from the branch back to trunk, that just doesn't make sense to me. The trunk is always aiming at the next release, but you keep branches in case you need to patch previous releases that customers are on. If your development process doesn't work like this, you'll probably need to figure something else out. In general, I favor generic code that is configurable enough to deliver to multiple users, rather than having a branch for each of my customers. These kinds of things heavily influence your use of any version control system. HTH, Rob _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
