I'm in the process of planning a migration from VSS to TFS and have come across a stumbling block when trying to merge from a Branches/Trunk-v1-BugFix subfolder to the Trunk folder. (The issue stems from the fact that the Branches/Trunk-v1-BugFix folder was originally branched from Releases/Trunk-v1).
My repository layout is as follows:
- Project1
- Branches
- Releases
- Trunk
Let's say I reach version 1 in Trunk development. At this point I branch the latest Trunk version to Releases:
- Project1
- Branches
- Releases
- Trunk-v1
- Trunk
Ongoing development occurs in Trunk. Meanwhile, to fix a bug in version 1, I branch the release version 1 of Trunk (in the Releases folder), to the Branches folder where it can be worked upon:
- Project1
- Branches
- Trunk-v1-Bugfix
- Releases
- Trunk-v1
- Trunk
Now, say I want to propogate the bug fix to the Trunk. Intuition tells me to do a merge from
- Project1
- Branches
- Trunk-v1-Bugfix
to
- Project1
- Trunk
But, when I try to run the merge wizard, the target branch dropdown only lists
- Project1
- Releases
- Trunk-v1
as a possible target branch. I don't want to merge to the Releases folder because that would put it out of synch with our delivered product. Is there a way to propogate the change to the trunk directly without using a baseless merge I am also open to alternative repository layouts if anyone has any recommendations.
Merge Limitations Caused by Branching Hierarchy
Hot Topic
- Copy to clipboard
- Not getting email alerts on checkin?
- recording using fiddler
- Copy or transfer data from portal to portal
- TF61002 CQConverter: Unknnown Migration Error Message
- reusable functions
- Project inheriting
- SendKeys in Visual Basic Express Edition 2005
- Test Methods that Retrieve Data from Different Tables
- Threading Question
VS Team System
- Newbie needing help
- Alphabetically ordered allowed values
- Using AdditionalVCOverrides
- Schema Comparison - Default bindings
- VB2005 and microsoft access
- windows service
- VS crashes when trying to change database connection in a SQL Project after installing datadude
- Permission - How do I deny delete access only for contributors?
- Link
- Problems with libcurl
Merge Limitations Caused by Branching Hierarchy
pixelord
Pinkpanther_120
I think you can solve your problem with just a small change in your branching strategy. Since all future development will be done in the Trunk (version 2.0, for example), you should create a Branch for the release. This will give you something like:
$\Project1\
$\Project1\Trunk
$\Project1\Branches
$\Project1\Branches\1.0
$\Project1\Releases
If you do this, all development for the next version will be done in the trunk, but the maintenance of version 1.0 will be done in the branch. Any fixes you make to 1.0 can easily be merged into the Trunk so that version 2.0 will not have the same bugs.
Once the 1.0 branch is stable, you can branch a copy of it into the Releases folder. In my opinion, branches in the Release folder should have no future (called a Tag in other systems). This allows you to quickly replicate any version of your product, and since branching is "cheap", it doesn't take much space. After some time, you'll end up with something like:
$\Project1\
$\Project1\Trunk
$\Project1\Branches
$\Project1\Branches\1.0
$\Project1\Branches\2.0
$\Project1\Releases
$\Project1\Releases\1.0_GA
$\Project1\Releases\1.1
$\Project1\Releases\1.2
$\Project1\Releases\2.0_GA
Hope this helps!
JR Lyon
Paradigm Shift
simmons