I have some general purpose classes in one project that I would like to branch to another unrelated project in another TFS folder that I have mapped to a different workspace. I would prefer branching to plain copying to keep the change history and be able to merge back any changes.
However, when I try to branch the file in TFS, it complains that no appropriate mapping exists. Is there a way to branch across workspaces?
It turned out that I just had to select my source control explorer workspace to be the target workspace rather than the source workspace, then branching was allowed.
Now the files appear in the other project with history and possibility to merge back.
No, that's not possible - at least not that way.
But if you have general-purpose libraries, which are used across various applications, you should reorganize your project and workspace structure anyway...
If you had for example two solutions, which partially include the same project(s), and then would map each of these solutions to an individual workspace, then it should work.
HTH.
Thomas
Related
Another developer has some test files in a new directory in their branch. They're useful to me as well but I'm working in a totally independent, newer branch and he's not likely to merge his branch anytime soon.
I am able to branch his "test-data" directory into my branch but I really want to break the branch association so they're treated as new files in my branch, i.e. so TFS thinks our branches independently added the same new files and we resolve conflicts later since our test data is likely to diverge.
Is there a way to "orphan" the branched files somehow?
You can just get files in TFS using the web access component. Just browse to the folder through the code portion of web access and right click > get as zip.
You can do it from the command line as well but I am not familiar with that. SO has a lot of resources on how to do that from what I have seen.
It is possible to break the branching relationship in TFS and there are many questions on SO on how to do that. But your branch wouldn't initially treat them as 'added' and the history will be in TFS. I would recommend branching just the folder his useful code into your branch and leaving that relationship for posterities sake.
That being said, depending on your situation it may not make sense. If you want to remove the branching relationship immediately, then I don't think you need to use TFS.
Our Visual Studio 2010 Solution includes six projects. One of the six is the main application and the remaining five are class libraries that are configured as Project References in the main application. Our TFS Source Control structure is as follows:
TeamProject\ClassLibries\Class1
TeamProject\ClassLibries\Class2
.
.
TeamProject\WindowsApps\Application1
I need to create a Branch of Application1 so I have this:
TeamProject\WindowsApps\Application1
TeamProject\WindowsApps\Application1-NewFeature
My question is, when I create the Branch for Application1, do I also need to create Branches for the five Project References whether they get updated with the new feature or not? If I do, do I need to manually update the Project References so Application1-NewFeature knows to reference Class1-NewFeature instead of just Class1? When I merge the new feature back into the main branch, do I need to update the Project References all over again? Branching is totally new to me and I'm afraid I'll have a mess of Branches and Project References that gets out of control. What is "Best Practice" for this scenario?
I find it best, in effect, to branch the entire solution or system of solutions. It doesn't duplicate files, so it's not a big deal to have projects in your branch that you're not going to change.
Ironically, one rule of thumb that I use is that anything referenced via project references should be branched together.
Using TFS 2010 I need to build a solution that depends on a couple of other solutions held in different team projects. I'm editing my build definition and I create a list of "Projects to Build'. When it comes to build the parent solution I get an error because it's unable to reference assemblies created by the other solutions. So I go back to edit build definition and add /p:ReferencePath="c:\builds\3\referencedproject\binaries\" to the "MSBuild Arguments" Build process parameters.
Problem is, I don't want to hard code the c:\build\3. I guess there may be a $() property I can use in its place - can anyone please advise?
The other problem I have is that the 'Main' project and the two other projects that it references live at the same level in the source code. As far as I can tell, I have to set the source control folder to be the level above this - which happens to be the root. This means that TFS Build does a get of all the projects on the root - which includes dozens of projects that are not required for my build. It's not a critical issue since it makes no attempt to compile these non-related projects but it does increase the time for the build cycle to complete. Is this only way to avoid this to "group" the projects that are required for my build into a different TFS source folder?
For the references issue there are a few options. The most common one taking an explicit dependency on a specific version by checking in the binary to TFS.
For example, if you have Team Project A that has a dependency on Team Project B, I would assume they are setup as separate projects because they evolve differently, probably have different teams working on them, and have different release cycles. The common approach to managing this dependency is to checkin B.dll into Team Project A (usually in a lib folder specifically for this purpose), then use a file reference from within Project A's solution/projects to the dll in the lib folder.
This approach lets the Project A team explicitly choose which version of B.dll they wish to depend on, and make an explicit decision to adopt newer versions of B.dll on their own timetable.
For the other question of how to have a build definition download only select source code paths, you can specify multiple lines in the Workspace mapping screen when setting up a build definition. For example you could have the following:
$\ProjectA -> $(SourceDir)\ProjectA
$\ProjectB -> $(SourceDir)\ProjectB
This would download Project A + B but not C.
I'll start with problem 2 as this should be easiest to solve.
You have 2 options both involve changing the workspace mapping of your Build Definition.
You don't have to map at the folder "above", you can map individual folders so if your source looks like this.
$/TP/SolutionA
$/TP/Folder1/SolutionB
$/TP/Folder1/SolutionC
$/TP/Folder2/SolutionD
and you only want to include SolutionA and SolutionC in your build, you could set the workspace up as follows.
This will get just the code you need and preserve the relative paths between them.
Another option is to use cloaking, you map the "Root" folder and then cloak any folders you want the build to ignore.
Both of these methods will restrict the amount of source being downloaded when the build runs, and also prevent "continuous" builds from starting when checkins occur in the folders that haven't been mapped / Cloaked.
Problem number 1.
As Dylan suggests, probably the best thing to do is to use Binary References between solutions. Especially solutions in seperate team projects.
Check out my answer to this question for a full description.
I am using TFS. I created a branch for one of folder/project in my solution. Now I have two branches (folders) with the same code. But my solution pointed only one (parent folder-branch. But from now I want to work with newly create son folder-branch.
I found two ways:
Redesign my solution to point newly created son folder-branch. My solution includes near 200 projects and this way will take a lot of job.
Don't change solution but change workspace by clocking parent folder-branch and mapping newly created to old place. This way also very complicated.
May be somebody will give me advise to another way. Easy way of using the same solution for several branches.
Typically you will want to branch and merge at the solution level, not the project level.
I have been following the ALM Rangers' guidance on branching, using their "basic" branching structure:
Created a "$/TP/Main" folder
Converted it to a branch
Created a "$/TP/Dev" folder
Branched from Main into "$/TP/Dev/Dev"
Created a "$/TP/Release" folder
Branched from Main into "$/TP/Release/Release"
My normal workspace maps from "$/TP/Dev/Dev" to my local "C:\TP" folder. That's where I do my day to day work, and the solution files are under there. When I merge forward to Main, and then to Release, the solution naturally comes with it.
The solution doesn't refer to any branch. It contains references relative to the disk location, so it all works in any branch or any machine.
This question is a derivative of a previous question: How to version resources that are shared across projects
I have a project that contains code that is consumed by many other projects. Specifically, one folder in this parent project has been branched to dependent child projects.
We have since made changes in the parent project and checked them in. In Source Control Explorer, I right click on the branched folder in the parent project and select "Merge", intending to push the changes to a dependent project. I select the child project as a destination and then select "Latest Version". The wizard informs me "There are no changes to merge."
From my perspective, this isn't true, since the recently updated files are clearly different.
Is there a fundamental misunderstanding of the merge process in TFS here? What do I need to do differently?
The TFS merge engine relies almost entirely on history, not file contents. This makes it efficient for very large trees, and flexible for tasks like safely cherry-picking changes -- but it also makes answering your question difficult.
The first step is to understand the diagnostic commands tf history, tf merges, and tf merge /candidate. Here is a good introduction: http://blogs.msdn.com/dstfs/archive/2009/04/15/a-note-on-merging-and-the-use-of-tf-merges-tf-merge.aspx
If you are new to branching & merging in TFS then your history is probably not very complex. I think it's likely you'll find your answer with one quick call to tf merges. However, tracing merge history can become extremely convoluted in the general case, so if you have trouble feel free to post back with more details.
Go to one specific file you know has changed in your "parent" project. Try merging just that file. Don't check anything in; just see what happens.
Something to watch for: The merge tools will not include files that have been added after you branch. You have to branch new files explicitly before you can merge any further changes. If a file is added to both parent and child folders without using a branch operation, the merge tools don't treat them as versions of the same file (and you can't merge changes between them).