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.
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.
I am working with my co-worker on some files, that are in TFS repository. We have to share these files frequently, however, in the process of our development they are neither compilable, nor working properly. We don't want to put them in the repository, because the rest of the crew shall have problems with compiling the solution. However, the manual sharing would be rather painful. Is there a way to put files on TFS, but not inside repository? (mark as temporary, not finished or something like that).
You can use a shelveset - if you shelve your set of changes then your colleague can pick them up and the other members of the team will never see them. It is a bit of a PITA as you need to have 2 shelvesets (1 each as you can only update your own). The only other way is to branch and then merge when you have compilable code.
Another option is to branch the code into a new branch that the two of you use. When you are done working on the file, and it will no longer break the main build, you can then merge that file back down to the development branch.
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
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).