Branches in TFS are physical or Virtual? - visual-studio-2013

We have Branched our TFS based code and and when got latest version it created a separate physical directory on our machine unlike git where we can have only one copy at a time and can switch the branches?
Creating a separate physical directory is just like creating a separate project, i am confused about TFS branching concept. Is it something central on server or it is creating separate directory on server too?

The branches in Team Foundation Version Control (TFVC) are separate "directories" on the server also; the branch folder "keeps" only the differences from the parent folder so the size of the stored data is far less than the double of the parent size.
And yes you'll have two different folders for the same project on your local workspace; three's no concept of active branch.

Related

How to pull from a new branch in TFS by copying local contents from another branch

There are two branches in the TFS repo. Branch 1 and Branch 2 . Branch 2 was created recently and I want to pull contents of branch 2. I have pulled branch 1 in my machine. As there is limited bandwidth, I was wondering is there any way to copy the contents from branch 1 folder into branch 2 folder in my local machine so that I won't have to utilize much of my mobile data. I tried it but source control explorer in visual studio is not detecting the files I copied to branch 2 folder from branch 1.
Is there any tricks to make it work?
Update:
Since you use TFVC, you need to make sure the folder you try to copy
to has been mapped to Branch 2. And you should be able to see the copy
files detected in Excluded Changes after you copy the files in the
mapped folder.
When you connect to TFS again, you need to perform “Get Latest” for
the Branch 2. If you modify files in the mapped folder, you would get
conflicts when you perform "get latest", choose keep local version,
and then the modified files will show in Included Changes, you just
need to check them in.
TFS provide two models of version control: Git and Team Foundation Version Control (TFVC).
Git is a distributed version control system. Each developer has a copy of the source repository on their dev machine. Developers can commit each set of changes on their dev machine and perform version control operations such as history and compare without a network connection. Branches are lightweight. When you need to switch contexts, you can create a private local branch.
Team Foundation Version Control (TFVC) is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.
If you use Git version control, you can create a private local branch and push the commits later. If you use TFVC version control, you would see the copy files detected in Excluded Changes after you copy the files in the local path of the branch. You can promote the changes as new files, which will cause conflicts when you check in.
For your scenario, Git version control will be more suitable for you. If you use TFVC, you can migrate them to Git repos:
https://learn.microsoft.com/en-us/azure/devops/repos/git/import-from-tfvc?view=azure-devops

Server computer died and the repositories were lost, how to recover?

I had a server that I linked to my current PC as "Z:\", and I had a repository there that I used for my programming commit/updates. There were multiple people working on the program, which warranted the need for a repository. We worked with Visual Studio and VisualSVN.
Unfortunately, my server died and we couldn't get it to start back up, so we've lost the repository. I have since bought and replaced my old server with a new one, but I'm having trouble re-creating the repository. For argument's sake, let's say that the copy of the program on my PC is the most updated one. How do I re-create the repository so that everyone can update/commit from there again?
In case there are multiple users who need access your repository, you should use a server, not direct file access schema (file://).
You must plan a backup strategy for your server and the repositories.
If you lost the storage that was holding the repositories, you lost the revision history of your projects. However, you should have the local copies of the project's data on your computers in form of working copies.
Search for working copies of your projects. The working copies will help you recover the latest state of your data and import it to a new SVN repository. Make sure that you do not import the hidden .svn metadata directory.

TFS - Creating a Branch from Label, Impact on shared projects

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.

Branching source to a different location TFS

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/

Two Different CVS servers (remote and local) for one project (CVSNT, WinCVS client)

There is a project that uses CVSNT/WinCVS for Version Control. This is the central repository. Locally checked out folders contain hidden sub-folder called "CVS".
I tried to install CVSNT server locally and use second instance of WinCVS to manage(version control) local temporary changes before committing to the central repository.
But that is not working because when checking out from the second(local) repository it still uses "CVS" sub-folder name for its working files.
Anybody knows if it is possible to configure CVSNT server and/or Client to use different name for this sub-folder? And if yes, how?
So far I'm using TortoiseSVN. It creates folders too, but they called ".svn" so there is no interference. It is integrated in Windows shell, which I don't like.
A sandbox is tied to a given repository (which is regitered in one of the files in the hidden CVS folders). You can't use the same sandbox to commit locally and remote (are you tring to mimic a DVCS? Use one of them if you need them). You can't change the folder name (but changing the CVS source files...), but beware WInCVS use them as well because they contains informations about the files status.
You have two options:
The CVS way: create your own development branch, commit to that, merge with the main branch when your code is ready. Of course the CVS server has to be reachable all the time.
The DIY way: create two sandbox, one from the local repository, one from the remote one, move files between them as you need. This is a more error prone way, IMHO.
Of course you can try to use two different VCS, but you will end up with a lot of headaches then. Better to use Git, Mercurial or the like that do what you need without any special configuration.

Resources