Migrating from local TFS 2013 to VS Online?
-
Hi all,
We're a small development team, and have our own TFS 2013 server. For a couple of minor projects, we created some accounts with Visual Studio online, and have found this preferable to our own TFS. We would like to move all the source code and revision history from our local TFS into VSOnline. Sounds simple, doesn't it? My googling to far has revealed two methods:
-
an unofficial tool which has mixed reviews. https://marketplace.visualstudio.com/items?itemName=vs-publisher-1455028.OpsHubVisualStudioOnlineMigrationUtility I am attempting to download this and see if I can run any test migrations with it.
-
an official Microsoft approach https://www.visualstudio.com/en-us/articles/migration-overview Sounds hideous, as I am not starting with a supported TFS version, and it won't import my collection into an existing one in VSOnline. Yuk.
Are there any other strategies? Surely someone must have done this? I expected Microsoft would have a very slick process built-in to VSOnline, since they presumably want everyone away from their own stuff and onto their cloud offerings - but it seems not.
I don't care about all the user stories etc. My main concerns are the source code and the associated revision/changeset history.
Any suggestions welcome.
Cheers,
Richard.
-
-
Well, having no knowledge of the internals, and knowing you probably won't be given direct database access, I'm willing to bet you're SOL? You might get away with some kind of replay system,but I wouldn't know...
-
@richw From what I understand, whichever source control you're switching to, always switch to Git first. That's because Git provides connector to move from / to any major source control solutions in the world.
Not to mention that VSTS officially supports using Git (or TFVC, the traditional one) for the type of source control.
-
-
@Tsaukpaetra sorry, daft question, what is SOL?
-
@cheong hmm, I had not considered moving to another solution entirely. Must admit, my main experience has been with VSS and TFS. I have only grabbed a few projects for a nosey with CVS or SVN. Our team quite likes the code review system and the tight integration with Visual Studio, but maybe other source control systems provide that too.
I shall see what is possible using other systems as a conduit. Thanks.
I honestly thought Microsoft would make this easy with a point-and-click installer, but no...
P.s. sorry for the delay, I ended up being out of the office for a few days.
-
@richw said in Migrating from local TFS 2013 to VS Online?:
@Tsaukpaetra sorry, daft question, what is SOL?
Shit Outta Luck
-
@richw said in Migrating from local TFS 2013 to VS Online?:
Must admit, my main experience has been with VSS and TFS. I have only grabbed a few projects for a nosey with CVS or SVN.
OK, the big recommendations first: don't use either VSS or CVS for anything new and migrate away if you can. They're not quite as bad as zipping up your code directories and mailing them to everyone every few days :) but they really have a lot of down-sides.
SVN is OK (and maybe TFS is too; I've never used it for real) if you want a centralised version control system. It's certainly better than it used to be (it used to have some horrible misfeatures in the merging department) but it's still a bit kooky in places. If you're lucky, your IDE will hide virtually all of that stuff and make it easy to use at least in a basic way. (The really big difference between SVN and CVS is that CVS versions the files independently, but SVN versions the entire directory tree as a single thing.)
Git is a “popular” distributed version control system, which allows it to support some usage scenarios that SVN cannot handle at all (such as off-line use; a big plus for me as I've got a long commute). The command-line for it is deeply and fundamentally arcane, but some IDEs manage to hide most of the complexity. I do not know whether your favourite one does. If you're going to use git, you need to decide if you're going to use a workflow based on merges or rebases and fast-forward commits, and it's almost as if this is a decision with religious significance. (I'm keener on merging workflows as I think they're more honest, but others disagree.)
In any case, it's worth investing the time in learning how to read history graphs.
-
@dkf I've used both TFS and SVN, and they're pretty comparable in terms of features and ease of use
-
@RaceProUK said in Migrating from local TFS 2013 to VS Online?:
@dkf I've used both TFS and SVN, and they're pretty comparable in terms of features and ease of use
I'll add remark that "as long as you use a latest version of IDE" for TFS.
We still of some of our programmers able to use VS2008 only because of licence count (i.e.: budget), when we tried to move to TFS2013, the MSSCCI provider that we used to bridge VS2008 freeze the IDE for a long time each time you want to "get latest version" for the solution.
In the end, only projects that the whole team have VS2012 or above can migrate, the others projects including a major project that almost everyone in development department need to have access to still remains in SVN.
WTH the old version of team explorer cannot be used to access newer version of TFS at all? For the other source control solutions older clients can still be able to access newer server, just with new features inaccessible.
I personally considered this a serious downside of using TFS.
And btw, the other "gitches" that I found annoying when using TFS is that, to see the latest changeset number, you have to go to "Source Control Explorer" and select "View History" from there. While in SVN days we can just right click the solution in "Solution Explorer" and select "View Solution History" to get that information.
-
OK, so I thought this was due a little update. I spent some time farting about with the DevOps Migration Utility: it's absolutely dreadful to use, but I did manage to get it to transfer one project with history. Sadly, it simply injects all the history into VSO dated as now (although in the correct chronological order) and by me!!! So the whole point of the history, to see who changed what and when, is lost.
Time pressures meant that I had to bite the bullet and go for Microsoft's initial recommendation, which I still think is pure evil: a 'get latest' on the solution(s), unbind from source control, then re-bind and add to a new source control system. So everything gets marked as being created by me today, and we lose branches. Marvellous. :(
There are some silver linings:
-
I took the opportunity to only bring across stuff which is current being developed or used (i.e. published on a live web server). So years of junk and test projects are not cluttering up the new environment.
-
I know that everything builds when you do a 'get latest' on a fresh PC: not always the case, as over time, people sometimes add critical files (but do not do so properly), or check-in nuget packages etc.
-
The old 'on-premise' TFS server has been removed from its HyperV host and pushed into Azure. It can be turned on as and when required for the odd browsing of the history. So if I absolutely need to know who did what and when, there is a way...
Despite that, I still feel unclean!
-
-
@richw said in Migrating from local TFS 2013 to VS Online?:
OK, so I thought this was due a little update. I spent some time farting about with the DevOps Migration Utility: it's absolutely dreadful to use, but I did manage to get it to transfer one project with history. Sadly, it simply injects all the history into VSO dated as now (although in the correct chronological order) and by me!!! So the whole point of the history, to see who changed what and when, is lost.
Time pressures meant that I had to bite the bullet and go for Microsoft's initial recommendation, which I still think is pure evil: a 'get latest' on the solution(s), unbind from source control, then re-bind and add to a new source control system. So everything gets marked as being created by me today, and we lose branches. Marvellous. :(
There are some silver linings:
-
I took the opportunity to only bring across stuff which is current being developed or used (i.e. published on a live web server). So years of junk and test projects are not cluttering up the new environment.
-
I know that everything builds when you do a 'get latest' on a fresh PC: not always the case, as over time, people sometimes add critical files (but do not do so properly), or check-in nuget packages etc.
-
The old 'on-premise' TFS server has been removed from its HyperV host and pushed into Azure. It can be turned on as and when required for the odd browsing of the history. So if I absolutely need to know who did what and when, there is a way...
Despite that, I still feel unclean!
If you have time, try export to Git first as I mentioned. From what I experienced from migrating from SVN to TFSO as Git repository, the check-ins information was well preserved.
-
-
@cheong Yes. 1. Convert to git 2. git push
