I want to branch my solutions to a different TFS server with TFS 2010.
Is there any way to do this?
You cannot branch between servers (or Project Collections) in TFS.
Do you need to do a one off move to a new server? In that case, restoring a backup of your current server to the new server and deleting the Team Projects you don't need might be a solution. If you need to be able to "merge" the code back to the original server at some point you could look at the TFS Integration Tools. This will allow you to move the code over to a new server and also keep the code synchronised.
However there are limitations with the toolkit, see the link for more information.
Why do you need to use a new server? Why won't a new branch in the current Team Project suffice?
Related
I have a couple of ASP.NET Core based projects being developed using Visual Studio 2019.
I am having issues where my workspace and TFS server on Azure-DevOps are out of sync. My PC contains the most recent code and I want to push everything I have on the server. I don't really care about the status of the TFS server as it is wrong. I just want to force everything to get pushed to ensure my PC and TFS are syncing again.
How can I force the TFS on Azure-DevOps to take all my files? I don't even mind removing the project altogether from Azure-DevOps and push all files as if this is a new project.
According to your description, sounds like there is something wrong with your source control binding. Or maybe some files outside of Visual Studio do not detect by TFS server. Which cause your workspace and TFS server out of sync.
If you want TFS server detect changes done to files outside of Visual Studio, the simplest way is using local workspace.
Now anything else changes files outside Visual Studio, your workspace detects the changes automatically.
It also detects adds or deletes but you have to include them to your Pending Changes manually with the link under `Excluded Changes
If you are using server workspace, this is kind like when you are offline, you cannot work with your local files because they are read-only until you check them out. So highly recommend you switch to local workspace, you just need to make sure you open the files in VS from a path which the same as your TFS local worksapce. Then it will auto sync changes in Visual Studio and show in pending changes.
More detailed information on the pros and cons of local and server workspaces, please refer our official link.
Now in your situation, we suggest you fist back up all of your local codes/files first. Then delete your old workspace, create a new local workspace.
Get latest from your sever, then copy all your back up to your workspace folder. Then let windows file system auto detect the difference between them, replace files download from server with your back up local version.
Now your local workspace should contain the latest version of your code/file, Visual Studio will auto detect the changes and list them in pending changes, if something added in excluded list, manually promote them.
Finally you could just check in/push all pending changes to TFS server. Now everything back to the track again.
Hope this helps.
I work from a small IT department and I'm pushing to move from our current TFS implementation to Visual Studio Online. My boss who gets the final say is hesitant because "What if Microsoft decides to stop offering the service, without notice, or their servers fail how will we get our code". While I find such a scenario unlikely and the scenario of our TFS server crashing and burning with no backups/bad backups much more likely. I still need to address his concern.
Does anyone know of a way to "backup" a remote TFS implementation? So far the only thing I've come up with is doing a nightly pull of Visual Studio Online and submitting it to a local repo, feels hacky, feels wrong.
Take a look over at the discussion on this StackOverflow question: Is There A Way To Backup Visual Studio Team Services Projects?
Here is Richard's answer:
There's no out of the box backup ability.
Now, if you are only referring to source control, and not work items,
pull requests, builds, test plans or anything else that the service
offers, then I'd suggest you migrate your code over to git.
With git every developer will have a complete copy of the source
repository, including all history and commit comments. From there,
it's a simple task to push the git repository to a different git
hoster (such as bitbucket or github) and make them your new centrally
hosted git repository.
On a historical note, Visual Studio Online at one point offered a data
export for a period of time. You might want to add a vote or three to
this related UserVoice idea to help raise the importance of the
feature with Microsoft.
Side comment: The business risks in using Visual Studio Online will
come from either Microsoft shutting down the Visual Studio Online
service or that the underlying Azure infrastructure has such a
catastrophic failure that your Visual Studio Online account is
unrecoverable. Both of those are extremely low risk, and very likely
lower than the risks you'd have running TFS on-premises, in your own
data centre, unless of course, your infrastructure and staff are
better than Microsoft's :-)
I agree with Richard. Visual Studio Online is not going anywhere :) You can also use tools like OpsHub, TaskTop, and Kovair to setup a two-way synchronization or use the TFS Integration Platform to do the same thing if you really wanted an option. If you are using Git repositories, you can clone the repository into other locations to maintain multiple copies. All of those options take effort.
I posted the same answer to this stackoverflow question.
We developed our own VSO backup tool. We scheduled it as a scheduled task and it runs once a night. It then
just clones all our repositories to disk.
Taken from this blog:
We use the VSO Rest API to query our VSO account and get all the data
we need. Since in VSO you can only have one Team Project Collection,
we retrieve all the team projects of the default collection. Each of
these team projects can have multiple repositories that need to be
backed up. A folder is created for each team project and saved to a
location on disk that can be configured in the app.config. When the
team project folder is created, the task loops over each repository in
the team project and creates folders for each repository.
You can also fork it on GitHub here
This question is asking, "Am I doing something wrong," or "Is this a failure in VS2010 and TFS?"
Whenever I open Visual Studio 2010, I habitually do a "GetLatest" from TFS, and often have it overwrite my local files whether they are updated or not just to be safe. I want to make sure that any code I publish has the latest updates from other team members. Then we all check in our changes as soon as possible in order to stay in sync, as the entire team uses this practice.
What we are finding is that when NEW code is checked in (e.g. a new aspx with code-behind) doing a GetLatest will NOT grab the new files. All we get are updates to files that already exist in our local working directory. Are we doing something wrong? Is there a checkbox we need to tick somewhere to force VS 2010 to get files that are new rather than just update existing changes?
This is quite common and is the result of your local workspace getting out of sync. If it happens a lot you should delete the local TFS cache. That's in %profile%\local\Microsoft\teamfoundation*.
The best way to completely eradicate the issue is to upgrade to a newer version. This was resolved with Local Workspaces in 2012 and with Git in 2013. Its pretty strate forward to upgrade.
I did a stupid thing and branched my project on my local disk instead of doing it on the TFS. So now I have two projects on my disk: the old one which has TFS bindings and the new, which doesn't. I want to merge those changes back into the TFS project. How would I go about doing that? I can't do Compare because my local branch has no TFS bindings. There should be some way to compare the differences between the two projects locally and then meld the differences into the old project and check-in, but I can't find an easy way of doing that. Any other solutions?
How about using a 3rd party tool to compare and merge.
You can always do a get on the source (c:\tfs\solution) and compare it with the local project (c:\myLocalSolution).
Check out the entire tfs solution for edit before merging your local to the tfs.
Our dev team is small (3 developers) and windows based.
I'm looking for a source control that can do the following:
Check out files for editing and warn others that file is used
Check in files and merge if they have changed
Split baselines for release versions and merge baselines if needed
Visual Studio integration
Can work over WAN
Thanks.
SW
Team Foundation Server fits all of those.
SVN would be great, as long as you use locking (normally the server has no idea what clients are doing by default)
Perforce might be a nice one to look at which does this more by default.
Both have VS integration, SVN especially.
SVN, provided that you explicitly lock the files. This is not by default, but you can easily lock the file via SVN commands or via TortoiseSVN.
VisualSVN provides the Visual Studio integration.
If you want good Visual Studio Integration, then check out Microsoft Team System. You didn't specify if you wanted free or commercial or how critical Visual Studio intergration was.
git will do almost all of it. Not sure about integrating it with Visual Studio though. there might be a plugin for that.
Reasons:
No central server needed. If you want one, you can have one, but it's not necessary
You can push/pull changes to the others at will.
Each of you can have your own local branches, and push only the ones you need to
each other. Branching/merging is easy enough to do branch-per-task. Then push just that task to a co-worker if needed.
Unlike SVN, only one directory is needed for git, in the top level of the directory structure.
git stash rocks for when you have changes in your current branch, and need to switch to another for a while. This is one of those things you don't miss until you don't have.
Merges are awesome.