I need to move some branches around next week if possible. (I’ve already put this off longer than I should have by over-researching potential side-effects.)
Planned Rename + Move Actions:
- Int\Main to Dev\Int
- QA\Main to Mainline\Main
- Prod\Main to Release\ProdLegacy
I have five questions that I could not answer from reading existing posts on various sites (including this branching guide and great discussion list). Does anyone have
Q1. Any issues you know of that will mess up our ability to merge existing branches after we rename + move our “Dev” and “Main” branches to different subfolders?
Will RI from child branch /Dev/Feature1 to relocated $/Platform/Dev/Int
(previously named $/Platform/Int/Main) cause serious merge issues?
If yes then what should we expect and will it just be a one-time hit to correct?
Will RI from relocated child branch $/Platform/Dev/Int to
relocated parent branch $/Platform/Mainline/Main cause serious merge issues?
I’ve tried reducing pending and committed changes in child branches, but many things just can’t be merged at this time (especially RI Int à Main).
Q2. How strongly would you recommend waiting to rename until after upgrading TFS2010 RTM (+latest updates) to
FYI, I’ll be scheduling a consultant to help get our partial TFS-SharePoint configuration uninstalled and then apply TFS2010 SP1.
Q3. Do you agree with ChandruR’s steps for
renaming a branch in TFS 2010 - or do you have your own steps (or better yet an example/template script! J)?
Merge all changes from the branch you wish to rename to all related branches, check in these merges.
Rename the branch and checkin the rename.
Re-merge to all related branches
Look at any items which have a merge, undelete from step c). Undo the merge on them and re-merge using /discard. e.g. if $/proj/target/1.txt has a merge, undelete on it
Q4. Can we treat the original ancestor branch as a child branch (just reversing the term RI and FI) or should we go through steps (and related risks) to reparent renamed ancestor branch?
* There is a reasonable chance that future livesite hotfixes from the ancestor root branch (soon renamed to
Release\ProdLegacy) will need to be merged back into Main (new root branch). Even though this is the ancestor branch such merges (FIs technically) it should be OK as long as only one Dev has rights to do these merges and RIs from Main to ProdLegacy
Q5. What happens to shelved changes if branch is renamed and then changes are unshelved?
My guess is that shelved changes might have the old branch path when unshelved. This could cause a bad move back to original location if checked in?
I think running the shelveset migration Power Tool command on each shelveset might be required to fix up paths for shelveset changes.
tfpt unshelve [MY_SHELVESET_NAME]
/migrate /source:CURRENT_BRANCH_PATH /target:NEW_BRANCH_PATH
Thanks in advance! -Zephan
Below are some additional thoughts and references I used to get as far as I can answering these questions online. Read on if you have spare time AND interest.
My ideal plan would be pretty straightforward:
- Tell all devs to commit (or delete) shelvesets they own and ask all branch owners to merge what they can before the rename date
- At least FI (forward integrate) to all child branches to reduce real pre-existing conflicts.
- Warn all devs what rename will do to their shelvesets and child branches (so they don’t get caught by surprise).
I’d love a clear list of known impacts to developers that have shelvesets and locally mapped workspaces before a branch is renamed.
- Take a full backup of TFS
- Rename + move the 3 branches
I would like to assume renaming/moving a branch is a fully supported action in TFS2010 that does not trigger unexpected post-move/rename-related merge issues.
- Tell devs to wipe and remap their workspace (so they don’t have lingering directory structure confusion).
I’d love to have clear steps and script commands to help devs easily get back to clean working state after a branch rename
- Fix build definitions to point to renamed locations
- Verify clean remapped local machine workspace and build definitions are working, make another backup of TFS, then call the rename a success
I feel like I’m being paranoid, but I haven't gotten a clear sense of how disruptive (=safe/risky) to rename branches is safe in TFS2010 per
this 2/25/2011 branching guide discussion (bold added for emphasis):
“…Renaming in and of itself
might not be bad. But renaming and then reusing the old name
might be something to avoid.”
Branch Structure Before & After:
$/<Team Project Name>
\Main (Root branch)
New structure (changes in bold):
$/<Team Project Name>
\Main (Root branch - was QA/Main)
\ProdLegacy (Root branch - was QA/Main)
Branch Renaming discussions:
How to Transition from Basic to Standard to Advance –
tfsbranchingguideiii.codeplex.com discussion (Bill Heys) – 2/25/2011
Like you have seen nothing but problems arise from renaming. Periodically I get cases referred to me from Premier support where things don't seem to be working correctly (merging issues,
upgrade issues from 2008 to 2010, and so on). Almost everyone of these cases has a *hidden* rename issue. Or the user deleted a file and added a different one with the same name. I don't *think* you will have a problem if you follow option one and rename Release
to Service Pack and branch a new Release from it (just don't use exactly the same name as the old banch :), maybe use RTM instead) . So I suppose you will be ok following that course of action.
Most of the rename issues I have seen have been on the development side.
I think 2010 handles these situations better so I wouldn't be overly concerned. Renaming in and of itself might not be bad. But renaming and then reusing the old name might be something to avoid.
Renaming branches in TFS2010 - But it works on my PC! blackmarble.co.uk – by Richard Fennell (MVP) on 2/4/2011
“In TFS 2010 behind the scenes a rename is actually a branch and delete process, this meant we ended up with the new branch, but also a deleted branch of the old name. This is not obvious unless you have ‘show deleted
items in source control explorer’ enabled…”
Related thread: Moved items in
TFS 2010 leave 'deleted' ghosts behind
Renaming Branches in TFS 2010 (ChandruR’s Blog) – by Chandru R. (MSFT) on blogs.msdn.com 6/9/2010
So my recommendations for this case:
1. Avoid renaming branches - a cleaner solution would be to, at the right point in your release
merge all changes to a parent branch and then re-branch to create a new branch hierarchy.
Or for the brave of heart :)
2. You will need to time the rename of your branch, to a point in your release where you can merge to all related branches. The steps to follow are: (see Q3 above)…
TFS 2010 wants to branch / merge every file -
www.stackoverflow.com thread ~8/25/2010
I believe the problem was that we had created the development branches, then deleted them, then recreated them. We ran into a problem similar to this in the past where a file was deleted, then a new file was added with the same
name. The fix for the past problem was to do a baseless merge. Rather than go through that we decided to just delete the development branches and rebranch them with different names.
TFS: Overwrite a branch with another - www.stackoverflow.com thread ~1/19/2010
"Delete + rebranch in
<TFS> 2005/2008 runs the risk of nightmarish-to-debug namespace conflicts in the future. " - Amen to that! – AakashM
Jan 19 '10 at 15:11
No problems that I can think of (apart from the fact that un-deleting the old branch would be difficult if you ever wanted to do that) – Martin
Woodward Jan 20 '10 at 16:01
(*Notice date is early 2010 so any TFS2010-specific issues likely unknown at the time.)
TFS 2010 SP1 rename/move fixes:
- A lock on a file is orphaned on check in when the parent is renamed and checked in in another workspace.
- A candidate delete is lost when you perform a merge in a folder rename.
- When you try to merge a rename and a delete on a file, the results cause inconsistencies in the version control database.
- When you convert a folder that has subfolders to a branch folder on a hierarchy root folder, and then you rename the folder and its subfolders, Visual Studio crashes.
- Unshelve reports bogus errors about a null DownloadUrl when dependent renames are shelved, and child item names overlap.
- An issue in merge causes a conflict not to be generated when there is a rename in the target and source.
Hopefully the above questions and background research give others a single location to make informed decisions regarding branch renaming. All comments are welcome, so chime in on any pieces or the whole thing.
Thanks! - ZephanS
(PS: Some content and lots of formatting got lost moving this from an e-mail I drafted. Sorry if I missed anything.)