Points to remember while branching in version control systems

That's basically all you need to know, but here are some other pointers:

• When checking in to the branch, always put the branch name in the comment, so that people can easily tell where the change is happening.
• You can always make a branch from a revision in the past, even far in the past. I've often seen developers fret about needing to create a fixes branch before beginning work on new feature work. You don't have to. Create the fixes branch when you have a fix to put on it, and create it from the last shipped revision, no matter how long ago it was.
• Branches usually have finite lifetimes. For example, a feature branch is obsolete once it has been merged back to the trunk. To keep your branches directory manageable, you can delete the branch when you are done with it. You still have the history of the files in Subversion, and can even retrieve the full branch later if you need it. By deleting the obsolete branches, you let develeopers update from the branches directory without having to wade through unneeded files.
• Subversion's strange rule about needing two revision number even to merge a single changelist prompted me to create this one-line script file:

  svn merge -r`expr $2 - 1`:$2 ../trunk $1

  This lets me specify the branch directory and revision number, and it pulls a single changelist from the trunk to the branch.
• If you need to merge only part of a changeset, you have two choices: one is to not merge at all, but simply edit the files on the branch to match the changes made on the trunk. Alternately, you can merge the entire changeset, then manually revert the files you don't want, or edit files to undo unwanted changes. Remember, the merge command simply edits files in your working tree, so any changes you want to make, you can make by hand.

Get more information

Can't find what you're looking for? Try Google Search!

	Web eshwar123.blogspot.com