Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Andrš Petr (EXT) wrote: > After reading about branching and merging in "Open Source Development > with CVS" book (and it look really scary) [...] It looks scarier than it is. It requires care and diligence, though -- especially in the beginning. Independently of mergepoints, maybe you consider these hints, at least for the first few attempts at branching and merging: - Always tag the codeline you are branching. This is basically the only easy way to go back to the root of a branch. - Tag both branches before a merge. This makes sure that no matter what you do, you always easily can go back to what you had before the merge. - Check out a few separate copies of the code, so that you have them present in your sandbox: the tip of the branch you are merging into (this one you obviously need in any case), the branch you are merging from (on a tag, so that you can't commit there, for reference), the branch you are merging into (on the tag you created in the step above, so that you can't commit either -- as reference during the merge process), and possibly the root of the branch (this may help you getting a quick overview what changed on both branches since their separation). - Get yourself a three-way visual diff application to compare the directories and files of the various local copies you created in the step above. Ideally it supports editing in place. - Resist the temptation to fix any bugs you spot during merging that have nothing to do with the merge process. Make a note of them, but leave them. This help separating the merge changes from other code changes, and can help analyse merge problems. This also ensures that a merge always changes only one branch. - Tag the branch into which you merged after the merge (that is, after the commit that follows the merge). This helps later analyzing the merge process if anything comes up that looks like a possible merge error. Mergepoints are not an essentially new functionality, they are a convenience. Instead of manually keeping track when the last merge occurred and executing the appropriate two-point merge command, you rely on the server keeping track of this and just tell it "merge in everything since the last mergepoint". If you have a tag on the source branch at the last mergepoint (and remember what tag that was :) you can achieve the same result with the two-point merge. > 2. Is it implemented on client or server or both? I think it needs to be supported by both. They are stored at the server, but the client needs to be able to send the appropriate commands. > [...] or is it possible to use other CVS clients (mainly those integrated > in Java development environment like IntelliJ IDEA or BEA Weblogic > Workshop 8.1) without degradation of functionality? I think no CVS client supports mergepoints. > [...] is usage of non CVSNT clients possible for users who will not > perform merges (they will only implement changes and commit them) > without any damage/loss of functionality of mergepoints and whole > repository? I think that works, as long as they don't do any merges. > 3. Here http://www.devguy.com/bb/viewtopic.php?p=1334 I found some > interesting article about mergepoints, but it says that merges can > happen only in one direction when using mergepoints. Can please somebody > clarify it? Mergepoints mainly store the position on the source branch where the last merge into the target branch happened. They don't change the merge process itself. Merging in both directions is complicated, mergepoints or not. When using mergepoints, you basically tell cvsnt: "merge in all changes on the source branch since the last mergepoint and create a new mergepoint" -- just as you would tell cvs(nt) when doing two-point merges manually without using mergepoints. While you can do that in both directions, the changes on the target branch that you would merge back to the source branch will include the merged-in code from the source branch, often modified to adapt to other changes on the target branch, which is likely to create conflicts when trying to merge back. > My idea is to create branch for these future features, merge changes from > trunk to branch regularly and after release happens merge branch to > trunk. (And probably create branch from release for fixes.) Many people do something similar. There has been a lengthy discussion here recently about such scenarios and the problems with bi-directional merging. Check out the thread "[cvsnt] Re: Branch merging - this seems wrong...". Basically, you merge your trunk regularly into your branch. At some point, this branch development is complete. Now you merge in the trunk, and after that, the branch contains all changes (now complete) from its own development plus all changes from the trunk. At this point, you don't have to merge this branch back to the trunk if you want it there, you just copy it to the trunk. There are several methods given for this in the thread I mentioned. Gerhard