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.
Related
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:
Here is a slightly different take on this question (Find the tfs path of merged branch), different enough to deserve its own question.
In the above link, the authors describe how you can programmatically traverse the folder hierarchy using TFS API to determine the parent branch object from a folder or item within a branch, and then you can get the branch information for that branch.
However, a different question is: how do you use TFS API obtain a path to a different branch of the original folder or item, taking into account that the item may have been renamed or moved in the other branch?
For instance: if I have an object $/MyProject/Main/Foo/bar.txt, I can easily figure out that the parent branch is $/MyProject/Main using the method described. However, let's I also have the following versions of this file out there that were created by branching the original files:
$/MyProject/Dev/Foo/bar.txt
$/MyProject/Experiment/Foo/bar.renamed
$/MyOtherProject/Main/openbar.woohoo
How can I determine the list of references to the specific files or folders in a branch? Clearly there is a way to do this because Visual Studio's merge dialog automatically populates the list of available targets with all references to the source file or folder, even if the source is not a branch.
If TFS has been used to move files or rename them, as opposed to using the file system and then checking in 'new' files to TFS then you can use the history window to review the full history of a file, this will show you it's branch history and also any moves / renames that have occurred, this is because tfs uses an identifier for the file rather than its name.
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.
I have created a basic admin system using RoR. It has very basic functionality such as users, roles, security features and a basic UI. I want to put this project into a master GIT repository.
If I want to create future projects, I'd like to use this base project as the foundation. Do I create braches?
MASTER PROJECT
MASTER PROJECT > SUB PROJECT #1
MASTER PROJECT > SUB PROJECT #2
So both sub projects are identical to the master project at this point. If I want to make a universal code change to any file within the MASTER PROJECT, how do I make that change trickle down to all sub projects. That is my FIRST QUESTION.
SECOND QUESTION:
What if I want to make a code change to a particular file on one of the sub projects?
e.g.: If I customize the layout in SUB PROJECT #2 (application.html.erb), I want that change only to affect SUB PROJECT #2. I want all sub projects to use the application.html.erb from MASTER PROJECT UNLESS it has changed (customized). It would be nice if SUB PROJECT #2 only contained the one customized file. All other missing files fallback on MASTER PROJECT.
THIRD QUESTION:
If I make a change to application.html.erb in the MASTER PROJECT, it is supposed to tickle that change down to all sub projects UNLESS one of the sub projects has a customized change to that file already. In this case, SUB PROJECT #2 does.
I'd want GIT to either:
a) Skip the update on application.html.erb on SUB PROJECT #2
OR
b) Prompt a warning to allow for some sort of merge.
Does that make sense? Is this setup possible? What would it be called? Where do i start?
Question 1:
You could use branches to track this. However, you should also consider whether what you need is simply a set of templates.
Git does not perform automatic merges by itself. You can write a script to do this, but otherwise you'll need to manually perform a git merge on each subproject branch.
Question 2:
Any branch you create will initially be identical to the original branch (master), at the time you created the branch. It will not change until you commit changes or merge in changes from the master branch. It wouldn't make sense to have this branch contain only the one customized file, so you may want to consider why you're asking for that if you want to use version control branches. The branch may only contain modifications to the one file, but nothing enforces this.
Question 3:
This is what git is designed for. When you do a git merge on the subproject branch, git will try to automatically merge the content and if it fails it will mark a conflict and allow you to manually perform a merge. You can also tell git to use another merge strategy, such as 'keep the local version', but this is a more advanced technique, and probably isn't what you want.
I recommend you start with the git-tutorial and make sure you have a good understanding of branching in git. Then, revisit this idea and make sure it still makes sense for what you're trying to acheive.
Maybe it's the right choice to put your master project into its own repository and make a new one for each project. There's git submodule which enables you to integrate other repositories in a project. YOu should try to have project specific changes only in the relating repositories, changes on the master project you can update via git submodule!
I've got a situation that I'm not sure if I can work around.
I've recently started on a new team that had never used any type of Version Control system, and our organization uses TFS as a standard (which I'd never used before).
After a lot of pleadind, I got the admins to creat a TFS project for my existing code on our server, and since none of my project's code had ever been checked in (after many years of existence), I wanted it in version control asap, so I checked my project into the root folder of the project. Not having read the Branching Strategy at http://tfsbranchingguideiii.codeplex.com/ I hadn't setup "Main" and "Release" folders in my main project.
At the time, I had separate folders on my local workstation containing the different releases we had made. I checked each version in, labeled it with the release number, and then checked the next version in on top of that.
I'm now running into an issue/bug with one of my previous releases and I'm trying to branch off a label in order to make some changes in one of my releases. TFS throws an error that I can't create a branch in that location (because all of the source in under the main project folder).
I've tried creating a "Main" and "Releases" folder, and then moving all the source under the Main folder, but the trouble is that the history and labels are pinned to the original location which is the root folder. If I try to branch off a label, the label doesn't exist in the "Main" folder that I moved the code to, but rather where it was created (in the root).
As such, TFS is still trying to branch from the root folder when I attempt a branch from the label.
My question is this: As an administrator for the server, is there a way to move everything (source, history, and labels) from their original location?
Thanks!
I don't think you can "move" the history and the labels. As you say, they're bound to the original source location. A move is effectively a rename.
In my experience, even renames of folders to folders that were deleted have caused those new folders to acquire the deleted folder's history.
Have you considered branching your current team project into another team project while observing the folder structure that you want in the new team project.
Create a new team project with the folder structure you want. E.g.:
/NewTeamProject
/Main (branch into here)
/Src (or whatever your root source folder is)
/Doc
/Releases
You can then keep the old team project around for "insurance".
It shows how helpful it is to have a reasonably thought-out folder structure.