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?
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.
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.
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/
We develop with Visual Studio 2010 (in C#) and migrated a while ago from SVN to GIT. Now we try to split up our repository (which is quite big - ~30.000 files) to many git repositories - one for each solution.
The solutions share some projects, mostly libraries we develop in-house and like to add to from all the solutions.
The new repositories have a flat layout. One subdirectory for each project (shared projects are submodules).
In the big old repo, the projects are in a tree structure.
The Problem occurs with external references in the submodules. In the new repos, the path to a referenced project may be "......libs\someproject", while in the new layout the correct path would be "..\someproject".
We already had some edit wars concerning this and are not keen on more.
Half-baked Solutions I could think of:
use "Reference Paths" in ...csproj.user and exclude this file from version control (has to be redone for each developer and after each reopsitory cleanup)
use branches for each situation and try to teach everyone where "real" commits should go and where "environment-change" commits should go (submodules are already not the simplest concept...)
embed binaries instead of the submodules (but what about developing changes to the submodules? what about different log4net versions?)
Does anyone know of a sane solution?
Since you are asking for a sane solution, I can only advise you to look into setting up your own NuGet service (look at http://www.MyGet.org for inspiration)
http://nuget.codeplex.com/
IF you go down the route of package management, consider OpenWrap. However, embedding the package management artefacts in source code is a bad idea. You can use such tools to update what is actually stored in submodules, but don't rely on them at build time. Expect the binaries to be there from the point of view of your build scripts.
So if I understand you correctly, the problem is with Visual Studio and not with Git? If that's the case, use the old tree structure that worked with Visual Studio. Make your submodules structure a tree structure too. So the top of the tree would be one super repo whose sub modules (the branches) would have submodules of their own, until you get down to the leaves of your tree. It would be a pain to setup at first, but it should just work.
Use one submodule to house all "common libraries". Just one level. But you should move the common libraries as services with well defined contracts. This way you can incrementally rollout new versions with no down time. This way you only have a submodule in each that holds the contracts. These could be interfaces or messages.
I have a similar problem using VS 2013.
I want to use git-svn instead of SVN directly. SVN has a gigantic set of directories. I could not create a single git-repository that would contain all of our trunk folder. Git-always exited with an error and the repository was corrupted. I worked around the problem by doing as follows:
Using git-svn, I cloned the subset of folders off SVN/trunk that I needed by creating one git-repository per folder.
Created a local parent git repository that contains all my git-svn-cloned folders.
Each git-repository was added as a sub-module to the parent git-repository.
The problem with Visual Studio is that it does not recognize the multiple projects outside the main project where I opened the solution. This solution is in a folder that contains the only files recognized by Visual Studio as being under git-source control.
I tried setting the git-preferences to use the upper level parent directory as the location of the git-repostitory without noticing any difference.
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".