So i just branched from my main project only to realize that i only needed to branch from one project within the main so now in my branch i have all other projects in which i don't need could i safely delete them from the branch?
OR
should i delete the whole branch folder using tf destroy and create a new branch from the main project which i only need. I tried deleting the whole branch folder but it is not allowing me to delete but i could delete some folders within the branch.
I just did the exact same thing you described. My solution was to convert the branch to a normal folder. Then you can delete the folder and check in the change.
It depends on how tightly coupled this code will be to the main project & how many dependencies it has on your other projects. If it's entirely isolated & will not have any dependencies you're better off destroying the errant branch using 'tf destroy' & just branching the project to have a cleaner source tree.
Otherwise I'd actually recommend removing only the completely unrelated projects. Any framework projects you reference in the branched project should remain part of the branch as well just in case you need to change them, it can be done without impacting the main branch.
Related
I've read several posts about branch and merge feature of SVC and creating branches in TFS, following those steps I've created branch for a breaking change in a feature of ASP.NET MVC application,
After successful creation of branch, branched files (new files) excluded from application, attempting to include files in project will create duplicate signature errors.
so I've to carryout changes in original files (files available before branching) now I don't know actual purpose of branches.
If I need to work with existing files why do I need to create branch?
How to setup and configure branching operation in TFS Version Control?
How really it helps?
Edit:
Attached image
I've created a branch # controller folder (Source Control Explorer), After successful creation of Branch I found two directory in One Controller another Controller-Branch (which is excluded from project by default). Now in what set of files I need to work?
When I Work in "Controllers" file set, these changes push back to other developers and so I don't see any isolation of environment there.
If I need to work in "Controllers-branch" why it is excluded from project? when I attempt to Include "Controllers-branch" to project, code definitions, class names duplicated (i.e., these definitions conflicts with contents of "Controllers" folder)
Why there have two branches Controllers and Controllers-branch:
It’s because when you created a branch (branching and merging -> branch) based on Controllers folder, you also select Immediately convert source folder to branch (enables visualizations), this will convert Controllers folder to branch.
So based on your need, you should convert Controllers branch into folder (right click Controllers branch -> branching and merging -> convert to folder).
Why Controllers-branch is isolate from your project:
It’s because Controllers-branch is a branch, and the TFVC branch can achieve these 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)
So it should be works isolated. If your work own is not only updated files in Controllers folder, but also need to modify files for the whole project, you should create a branch from ApplicationMain folder a,d make sure Immediately convert source folder to branch (enables visualizations) is not selected. Then you can work on ApplicationMain-branch concurrently from other developers.
I have a project folder called as "APP1" . We are currently deploying code from this folder . we would like to create one more folder or branch so that Dev can easily checkin all their new changes without directly affecting the main folder .
Should we have one more branch of folder "APP1" so that Dev can checkin all their changes in the newly created branch and eventually we can merge all the new changes to the main folder "APP1"?
Is this a correct approach and how easy it will be for us to merge all the new changes to the main folder ?
We have team of about 4 developers working on the same project .
You can consider using Basic Branch Plan. The structure like this Development <-- Main --> Release. You can branch your project "Main" into two, one named "Development", the other one named "Release". All users can work in Development branch, after they test their code, then merge to Main branch. When you want to release your project, you can merge your code from Main branch to Release branch.
That would be one way to do it. You'll likely need to play around with differing branching and merging strategies until you figure out what works for you and your team.
There's a large guide put together by the ALM rangers for TFS branching and merging strategies. See https://vsarbranchingguide.codeplex.com/
Here's a picture from one of their guides describing the potential branching/merging strategies that may work for your team, depending on team size and release cadence:
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.
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
We are using TFS Continuous Development model
Main Trunk
-> Various Development branches
-> Various Release branches
All merging back to main trunk
Now we need some major changes to our folder structure and solutions
How do you handle folder restructure in above model of TFS usage?
do i need to draw line and create new structure from latest Main trunk and lock all branches and do updates then creates branches with restructured new trunk.
Or am i underestimating TFS, would be able to handle major folder structure updates and propagate over to branches. As long as i know if we move around folders in branch or trunk it don't like it.
TFS can handle this, and does it by "renaming" each file by changing it's TFS location path.
I've been able to do this in a child branch, merging it up into the trunk, and then back into another branch.
It does get a little tricky, and you are sometimes presented with confusing dialog boxes because it can't automatically resolve renaming changes.
When I got this box, I resolved any actual content changes in files. I was then able to cancel out of manually resolving every renaming change without any problems, and everything worked perfectly.