September 23, 2003

CVS Part III

Resolving Conflicts
I forgot to mention it earlier. When you commit changes and there are conflicts, the conflicting files will now contain both sets of changes, and it is up to you to go in and edit to fix this problem.

branching
I'll give a set of commands and explain them:

cd .. //get out of current working directory
cvs -q checkout -d new_folder -r Release_Name Project_Name // gets a working copy at the specified Release in the folder specified
cd new_folder
cvs -q tag -b Branch_Name // create a branch at the state in the working directory with the given branch name

two ways to get a check out files in new branch:
cvs co -d desired folder -r branch_name project_name // of course you don't have to use the -d option on check out
--or--
cvs update -r Branch_Name // this will try to merge changes in current working directory, so if you have changes you don't want added it is best to use the checkout method

if the working copy you have is on a branch, you can commit normally, and it will go into the branch

you can get back to the current version as always with:
cvs -q update -A

merging changes from branch to trunk:
(from trunk working copy)
cvs -q diff -c -r branch_name //this shows differences in branch and current versions
cvs -q update -j branch_name // -j means join

Resolve any conflicts as you normally would by editing the files with conflicts in them.

Trying to re-merge after new changes will cause conflicts because it looks at differences between the root and tip of the branch and tries to merge all of those changes. some of them have already been merged, hence the conflict.

To avoid re-merge conflicts

cvs -q update -j "branch_name:date -j branch_name // the first -j gives join a start point, and keeps it from using the root of the branch.

If you tagged the point at which you merged last time, you could do the following:
cvs -q update -j last_merge_tag -j branch_name

for this reason it is good to tag at every merge with a descriptive name (including the branch name in the tag is a good idea)

branching without first checking out a working copy of the release to branch

cvs rtag -b -r Release_to_be_branched_at desired_branch_name project_name

Posted by ultrabob at September 23, 2003 08:57 AM
Comments
Post a comment









Remember personal info?