We have very large project and we have to branch some of the sources. Branched sources should be stored in a different location (within the same TFS server).
The problem is that due to active development of the main project we have to merge changes from trunk every day.
So the question is: how should I branch sources to provide the easiest merging from trunk.
The desired scenario is:
pull changes from trunk. Resolve conflicts and merge changed sources.
push merged changes to branch (that is stored in different location - not as a branched version in the same location)
Is this possible without any complex scripts?
I am using Visual Studio 2013 for work with TFS source control.
You can have branch relationships been different locations in TFVC. You can branch from one team project to another and maintain the relationship.
If you currently have two locations that do not have a branch relationship you need to create one by doing a baseless merge first. One you have some a baseless merge you can then merge s normal As if they are in the same team project.
I would however recommend that you fix the problem that has lead to this situation. If you are going a single product then you should all be in the same team project.
http://nakedalm.com/one-team-project/
Related
I am looking for some ideas and suggestions on how to implement a class hierarchy type of structure of VS projects in TFS.
Specifically, I want to have a "base" project which will contain all the common functionality the rest of the projects will inherit. When the changes are needed in the "base" project it should be relatively easy to propagate these changes to the rest of the projects which are based on this "base" project.
The obvious approach is to branch other projects from this "base" project and merge up the tree from this root project when there are changes but I've never tried that before and would like to hear from someone who attempted something like this before or has extensive enough experience with TFS to be able to point to inherent issues or pitfalls of such idea...
The projects in source control is actually folders. So your question is somehow the same as how to structure your folders in TFS.
Your base project is the some concept of main in branch which is root folder that acts as a container folder for your main source tree, together with accompanying project artifacts such as design documentation, scripts, and test cases. The Main folder also usually contains your Visual Studio Solution (.sln) files.
In TFS you could convert a folder to a branch.Then you just need to branch your base project to other projects. After have a branching relationship, you will be able to merge changes between the 2 branches. Besides you could also use branches to accomplish the following goals:
Manage concurrent work by multiple teams on the same codebase
Isolate risks that are introduced by different sets of changes to the codebase
Take snapshots and then support subsequent isolated changes (for example, to create a release branch)
Although you can still branch and merge among folders, the best practice for your team is to branch and merge only among branches.
When you perform branch operations, branches have important advantages over folders. Branches support version control features that provide extra visibility into your branch structure and into where your changesets have merged. (For more information, see these wonderful links: Visual Studio TFS Branching Guide)
For inherent issues or pitfalls of such idea, one thing is you might have to resolve conflicts when you get, check in, merge, or unshelve. Another thing is permission. It's better to avoid everyone have permission to merge changes from the “derived” projects back to the "base" project.
Besides you can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy. If you are interested, you could check this blog which shows how to configure that.
TFS: What are the consequences of converting a source folder to a branch?
I want to create a branch from a folder in which we have our source code and I see the following option in "Branch" dialog in VisualStudio:
"Immediately convert source folder to branch (enables visualizations)"
Do I loose any information (e.g. file history etc.).
Are there any disadvantages to do it?
Thanks and appreciate your help.
Lerner.For.Ever
The release of Team Foundation Server 2010 began a distinction between branches and folders. The following illustration shows the top-level of the folder structure in Source Control Explorer：
As the illustration shows, you can still use folders to organize
branches within a team project's version control hierarchy. However,
folders and branches have a different appearance and different
capabilities. When you right-click a folder or branch and click
Properties, you display different information and different
functionality.
When you perform branch operations, branches have important
advantages over folders. Branches support version control features
that provide extra visibility into your branch structure and into
where your changesets have merged. (For more information, see these
wonderful links: Visual Studio TFS Branching Guide)
Although you can still branch and merge among folders, the best practice for your team is to branch and merge only among branches.
Above points are all related to the difference in TFS and VS, something about Trunk and main, you could take a look at the answer from Jesse Chisholm in Folder converted to branch?
Our TFS Source Control is setup like this:
TFS Project
Solutions
WebApp1Solution
WebApp2Solution
Libraries
SharedLibrary1
Web Applications
WebApp1
WebApp2
When I open solution WebApp1Solution, it loads my workspace with projects from Libraries and Web Applications folder.
I would like to suspend my current workspace environment for both web apps and all shared libraries and start working on a specific version of this code from an earlier label (our last deployment). We do not have any branching as of yet.
From what I've read, I think these are my options:
1. Shelve pending changes on the solution and get the specific label version of the solution. What would happen when I check any changes back in?
2. Create a branch in Source Control from the specific label version. Would I have to create the branch on all of the folders in the different locations? How would I switch back and forth between my current code and new branch code?
Any help or advice will be greatly appreciated! Thanks!
Just create a branch at your TFS Project folder into a development folder. You should actually be doing this normally for all of your development. Your mainline branch should never contain anything except for your production deployable codebase. You should always be able to get latest of your mainline and build and run as the production end product.
All developers/teams of developers should have their own TFS folder where they can branch from mainline, make changes, test, etc... then once it has passed all approvals, merge it to mainline and destroy your devline.
As for "switching" your branch is a separate folder from your mainline. You can open both at the same time in different instances of Visual Studio, just like opening two solutions at once. Branching creates a copy of the folder/solution/project structure from the point of your branch. Then when you merge it back it reports differences and attempts to merge. If there are conflicts you will be prompted to review and resolve them. Most of the time TFS does a good job at auto-resolving, but I always carefully review all conflicts before selecting a method of resolution.
How do we best perform a Baseless Merge between two branches of a TFS Database Project?
We have a change in Branch B that we need to merge into branch A. Can we make a Schema Compare in VS and just update?
You do a baseless merge just like you would regardless of the type of files that are in your branch (it has nothing to do with the fact that you are using Database Projects, they are treated the same way as any other type of project - just a bunch of files in a branch).
In the Merge dialog it will list in the drop-downs the branches that have relationships, but you can always browse for another target branch to initiate a baseless merge.
s/w versions:
TFS2008 server, VS2010, windows xp
I have the following branch structure in TFS
$/Root/Main Branch
$/Root/Dev/Project1
Project1 was branched off the Main Branch, few months ago. Now I need to merge the latest code in the Main Branch to the Project1 branch. During that time, some new folders were added to the Main Branch.(Main Branch/CoreDataClasses/..). So when I try to merge this new folder into the Project1 branch using the merge wizard, I don't see the Project1 branch in the list of target branches. Why is TFS not showing me my dev branch in the target branches list?
Do your merge from the root (where you branched), not the individual folder(s). Remember that merges aren't destructive until you check in, so you can choose to only check in the new folders if you want to hold off other changes.
With Tfs I've had much better experience merging from branch to the trunk and I think this might be the case here. Of course this might take a rethink of your strategy but it's doable.
I know this may be way offside but if you're doing cross branch merging a lot then definitely consider a distributed version control system like mercurial. I've used Tfs lots and really like it but when it comes to branching and merging it is a distant second to hg merge (mercurial command)
The folder structure between source and target have to be the at least 80% the same. If there was too many restructuring of the folder layout then I suggest you use the cmd line Merge with the force switch when doing the merge. See "Merge Command".