branching-and-merging

I have a branch that was developed for a long period of time. During the development default branch was merged into that branch several times. I would like now to review all the changes done on that branch ignoring merges, to decide whether it is safe to merge it to default. I tried hg diff -r "branch('myBranch') - merge()" but it still shows changes introduced by merges. Also tried following this How to show the diff specific to a named branch in mercurial but hg diff -r "branch('myBranch') - branch('default')" still bring changes introduced by merges. The problem with your commands is that

I've read in many places that renaming a branch is rather problematic in TFS 2010 : you may lose the history of the branch you just renamed ( as seen in this article or in this SO question ) I cannot find any mention of those problems in TFS 2012. Are there any consequences I should be aware of before renaming a branch in TFS 2012 ? James Reed The biggest problem with renaming a branch, is that you will effectively be performing a baseless merge next time you merge to or from the renamed branch. This can cause a lot of pain. I'm currently trying to untangle such a mess at the moment and its

Using TFS, we have the following: A main baseline A development branch for each development effort. These get merged back to the baseline. A release branch that is created with each release. Bug fixes are made here, released, and merged back to the baseline. Using shelvesets, we can share code across development branches if needed without contaminating the baseline. Useful for code reviews. When we deliver our development changes to baseline we have an automated build that kicks off and automatically places our changes on the test server. The problem is that the business analysts can't see our

Branching guidance usually describes an immortal "Main" branch, with features branched from Main, and merged back to Main, and Releases branched from Main, with further branches of a Release as necessary for Service Packs, RTMs, etc. The guidance regarding Main is often simplified to "no trash in Main." I'm working with a group that releases regularly (as often as monthly) and serially. To them it seems unnecessary to ever return work to the Main branch. They use TFS 2010--diagramatically their branching structure looks like this: Daily builds on a branch are made; eventually the branch goes

I am in need of help setting up a TFS branching structure. The current scenario is as follows, our application is a SaaS, and I believe we need multiple "Release" branches simultaneously. Going through the TFS Branching Guide III, I'm fairly certain that we will need the "Advanced" branching model. We start with having a "main" branch, which will house the application as it stands right now (we're coming from Visual Source Safe). From that we will create a "Development" branch, and leave that alone for now. We will also create a new "Service Pack", "Hotfix", and "Release A" branch tree which

We are trying to implement the "Basic Dual Branch Plan" as described by the ALM Rangers in the latest Visual Studio TFS Branching and Merging Guide . From the guidance: The basic branch plan with a MAIN, DEV, and RELEASE branch enables concurrent development for your next release, a stable MAIN branch for testing and a RELEASE branch for any ship blocking bug fixes. Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN. Additional releases are supported by creating release branches for each product