My usecase:
Currently have TFS 2012 (on Prem)
Want to move to VSTS
Want to migrate only the SourceCode with history, don't need any workitems, etc.
Questions:
1. What are the tools I can use?
2. Is it mandatory to upgrade to TFS 2018 first before migrating to VSTS
If you want to migrate the source code only then you have 3 options.
The MS recommended route is to upgrade to TFS 2018 and then use the Database import feature of VSTS. This is the only way to keep using TFVC and keep the full history in tact.
You could use OpsHub however this comes with limitations as it will "replay" the history so the changeset history will reflect the time of the migration rather than the time of the original check-in. Also if you have multiple team projects then you might need to pay for the tool.
If you only want the code and you are happy considering changing version control systems from TFVC to Git then this might be the simplest option. You could use Git-TFS essentially you would clone the TFS (TFVC) repository to a local Git repository. At this point you would have a full "copy" of version control including history and branches, but in Git instead of TFVC. You could then push this up to VSTS, the only "downside" is that you would now be using Git rather than TFVC, Git is good, but different so you will want to think about that.
Related
I have some projects on TFVC source control on TFS 2010. I want just to migrate the source code from TFS 2010 to TFVC on Azure DevOps Server.
I don't want to process an upgrade of the entire collection to a newest version. I Just want to transfer my code with history.
I tried Git-TFS. I cloned my repository on TFS 2010, but I don't know how I can update the remote URL for TFVC repos and push on Azure DevOps Server.
Any ideas how I can do it? Or other tools that I can use?.
In the case I decide to migrate without history how can I do it?
Thanks.
git-tfs is a two-way bridge between TFS (Team Foundation Server) and git, similar to git-svn. It fetches TFS commits into a git repository, and lets you push your updates back to TFS.
If you want to move code from TFVC on TFS2010 to TFVC on Azure DevOps 2019 and keep history.
You have to do the upgrade process of entire project collection.
In the case I decide to migrate without history how can I do it
You could just create corresponding new team projects and workspaces. Pull down your source code from your TFS2010 workspaces/projects. Copy and paste source code files/folders in new workspace. Then check in them back to Azure DevOps Server 2019.
We advise you keep preview TFVC repository of 2010 online but read-only to view history.
Same with Azure DevOps Service, hope this helps.
Disclaimer: I'm the last maintainer of the git-tfs tool (even if I no more work on it)
Git-tfs could be used to migrate from TFVC to git (with history and branches if your history is not too complex).
But in no way it could be used to push this history to another empty TFVC project.
So don't expect something from here.
Fun fact (not so fun for you) :
To prevent regression developing git-tfs, I created a TFVC project on Codeplex used to run smoke tests in a Continuous Integration job.
When Microsoft decided to close Codeplex, I contacted a guy working in the source control team inside Microsoft to help me migrate from Codeplex to Azure Devops (at the time called VSTS) which is the problem you try to solve.
I don't know if they put a lot of effort into this but no one was able give me a solution. The only thing they think about was to use git-tfs, that I confirm you is not able to do it!
That could give you an idea of the problem you're trying to solve...
Ps: that also show that TFVC is not an enough flexible source control and their is a much higher added value to migrate to git (like nearly everyone is doing it...)
According to Microsoft's migration guide (p. 25), the TFSMigrator tool that will migrate data to DevOps only supports the current version and 1 previous version of TFS which means migrating to the newest TFS version is integral in the process.
I'm using an old version of TFS which I wouldn't have too big an issue upgrading except the server it runs on is Windows Server 2008 which doesn't support anything past TFS 2012.
Since all I need is the code repository as it sits today (I don't care about work items, history, or anything else), is there an alternative method for migrating my code?
I'm okay with something semi-manual if necessary. I have about 30 projects to migrate so if I had to migrate project by project, that isn't a big deal. I'm just hoping not to have to recreate each project by hand.
Try git-tfs.
The process is:
Use git-tfs to turn the source TFVC repo into a local Git repo with all of the history preserved
Use git-tfs to "check in" the Git repo to the target TFVC repo
A few caveats:
It's going to be slow.
It's not going to be a full-fidelity migration; you're going to lose the dates of the checkins and possibly the identity of the person who made the checkin in the target system.
An alternative is to spin up a non-production modern TFS environment, clone your team project collection, upgrade it on the non-prod instance, then use the migration tool. That's going to capture everything with full fidelity, and that official tool is the only option you have if you want full fidelity.
I am looking for an alternative to branching in TFS with the goal of allowing multiple developers to continually integrate into a single changeset that is not in branch (aka a shelveset).
I know that a single user can update their own shelveset, and other users can pull that shelveset - but is it possible to allow several users to modify the same shelveset?
I understand that branching is preferred but I would still like to know if it is possible, maybe by using some sort of TFS powertool or modification.
No this is not possible. A shelveset is owned by a single user. it's also not recommended, as the shelveset is only a single snapshot of the change.
If you'd like something like this, you could consider git tf to create a local git repository which can be synced between two developers. Once they're finished one of the developers can push the change(s) back into TFS.
Moving from TFVC to Git has become easier with the release of TFS 2015u1:
Team Services | TFS 2015
In Team Foundation Server 2015 Update 1, a project administrator can add a Git repo to a team project created with Team Foundation Version Control (TFVC). You can also add a TFVC repo to a team project created with Git. This allows you to adopt a new version control system while preserving all the data in your team project.
As to ways to persuade people to move, that's a hard question. You'd first need to understand what is holding them back, explain the, what advantages Git brings, what disadvantages you see in the current setup. You will probably need to hand-hold or train them so they get comfortable with Git. Using git-tf for a while may give them more confidence to make the move.
What will I actually miss if basing my source code handling on TFS (to get all the integration and reporting etc) but use git-tf or git-tfs locally?
Will I then be able to use the complete git functionally to branch and merge locally just as if used a git based central repository, or will there be a different workflow and limitations to consider?
We use feature and release development branches a lot and like to keep doing so, how does actually the TFS server handle this when pushing these locally using git-tf etc?
Actually, git-tfs is more advanced than git-tf. I highly advice to use it instead of git-tf (for the moment).
With git-tf, you should clone each branch as a repository (and be unable to cherrypick, merge...) while in the last version of git-tfs you can do it and keep your workflow.
See https://stackoverflow.com/a/13710811/3619
If you know git there is not problem to use git-tfs!
The documentation : https://github.com/git-tfs/git-tfs/blob/master/doc/
just know that if you use :
git tfs checkintool
or :
git tfs checkin
it will create a merge commit
and if you use :
git tfs rcheckin
it will commit each local commit in tfs and fetch and rebase automaticaly on these commits...
But read the wiki documentation, it's clear enough ;)
edit:
Contrary to what #gbjbaanb said, there is a lot of advantages of using git-tfs instead of plain TFS (if you know how to use git...). ALL what you could do with git locally works and is still an advantage (light branching, rebase, local commits, reworking commits, knowing exactly which version is checkouted, fetching and seeing changes WITHOUT merging them with your current workspace, better history,...).
Now with git-tfs, you could even create more easily than with TFS a TFS branch (you just have to create it before doing a commit in it, or rebase onto after creating it if you began your work in a git branch before... ).
The only thing that is not better than TFS, for the moment, is merging 2 TFS branches that is not supported. You should either do a merge with TFS if you want to see the merge in your history (what we generally want) or merge with git and checkin in tfs (and you won't see the merge changeset :( ).
A pull request[1] to resolve all this (and permit to manage merge commit a LOT easier than with TFS) already done and waiting for merge in the trunc (I have just to refactor Unit test and the feature be reviewed).
[1] https://github.com/git-tfs/git-tfs/pull/363
If you use git-tf (the MS version) firstly you will have to understand the commands you use will be different - they stuck an additional "tf" in every command. (eg git tf push)
The second is that branching will not work like git - I found (and this could be due to security setups and suchlike, even though I can create branches locally and on the server) that whilst you can branch your local git setup, you cannot push a new branch back to the server - you have to merge it onto an "offical" branch first.
If using TFS, I wouldn't bother trying to use any of the bridges (though svn-tfs bridge is very close due to the nature of TFS being close to SVN). I'd use the native client. I wouldn't choose TFS first though, but if that was what I had to use - the Team Explorer Everywhere client would be my choice.
Does TFS support local commits?
In other words: Can I
modify the code,
make a local commit (without sharing these changes with others),
test my modifications and
if my changes didn't break anything, do a global commit (thereafter my changes are available to other developers)
in TFS 2012?
If it doesn't, are there any workarounds, which allow this functionality?
No it doesn't support this, however it does have a couple of alternatives you can use instead.
1) Branches - All developers work on their own branch then merge to trunk/main when they're happy with their changes.
2) Shelveset - developers shelve any change they don't want to commit yet. This lets you undo your change, or pass it to another developer on the team without losing the change or checking into the main branch
3) Gated Checkins + Unit/Automated tests. Any time a developer checks in, TFS Automatically shelves the changes and runs the tfs build + any associated tests (unit or automated). If everything succeeds then it is checked in. I don't believe this supports manual tests.
or a mix of all of the above.
TFS does not support this by itself.
However! Microsoft released Git integration with TFS. Brian Harry blogged about this: Announcing Git Integration with TFS a couple of weeks ago.
Using this setup you can use Git for your local commits and then commit it to Team Foundation Server.
Not for the on premise version of TFS (yet), but as of January 2013 Microsoft's hosted Team Foundation Service has Git support, which obviously supports local commits.
http://tfs.visualstudio.com/en-us/news/2013-jan-30.aspx#git%20support