I'm in the process of migrating some source code from an in-house system over to TFS 2015. I'm using the APIs via Microsoft.TeamFoundation.VersionControl.Client etc libraries.
Ideally I would like to also import the history of each item including who made the change and when.
The workspace.CheckIn method allows me to specify the "author" who made the change, but I don't think it's possible to supply the when.
Does anyone know if's it possible to "back-date" a checkin?
You can't change CreatedDate of a changeset. In fact you should not be doing this in the first place.
Even if you manage to change somehow then you will loose the track of when you really created/check in the changeset on TFS.
If you are upgrading older TFS to TFS2015. Which is a full data transfer. TFS sever will also include the back-date changeset. However you are using an in-house system, just the same as checking in code from local development.
So you may have to manually manage the source control history of your in-house system, such as import to a Excel.
Related
I assumed this would be easy, but I'm not finding anything on it...
I have a project in TFS 2010, which needs to be moved to a new TFS 2015 server. Apparently the project cannot simply be moved normally because it's using a different project template which is not compatible and causes errors when trying to migrate (so I'm told - I don't have any more details on this).
I'm looking for a way to bring over the changesets, keeping history, to the new server. I assumed there was some kind of "dump" where you could export the TFS changesets, then import them into the new server into an empty project - but I'm not finding that option.
TFS Integration is deprecated and apparently doesn't work for TFS2015, with no alternative listed.
I'm open to other creative options like temporarily exporting to a different version control system - for example, I've looked at SVNBridge, but I can't even get that working, let alone figure out if it would help here.
Is there a way to migrate all changesets for a given project and keep history, without migrating the entire project?
There is no default way to migrate changesets in TFS, you would need 3rd party tool, like OpsHub (some features are not free), to migrate the most commonly requested data. Check: http://www.opshub.com/products/opshub-visual-studio-migration-utility/
Or you may consider doing a upgrade from TFS 2010 to TFS 2015, which is a full data transfer. To understand factors that affect your upgrade's compexity, check the requirements and review the upgrade process.
Learn if a dry run makes sense for you, and weigh the benefits and the costs to perform a pre-production upgrade.
When you're ready to upgrade, minimize downtime with the TfsPreUpgrade tool - especially for very large TFS collection databases (> 1 TB). Follow these steps for how to upgrade TFS.
So I've been trying to perform a migration (code only, no work items) of a medium sized project from an on-premises TFS2010 to VSTS using the OpsHub tool. My user is an administrator on both sides, and the migration runs and completes without tossing errors.
The problem is that it just doesn't do what it says it will. I spent a long time mapping the users from TFS to VSTS during the setup, but it completely ignored that mapping and assigned every single changeset to my VSTS account. The docs also say that it should preserve the original TFS check-in time in the comment of the new VSTS changeset, but it never does that to any of them -- the comments are just brought over exactly as they were.
It seems like there must be a setting set wrong in OpsHub to turn these features on, but I can't find any kind of options screen or anything in the tool. It looks like other users are able to successfully map the TFS users to the VSTS users and have it work like you would expect, but I can't make heads or tails of it.
Thanks for any help or advice on this.
If you are using the free version then this feature is not supported by it and same is mention on the visual studio gallery download page, only the commercial version of migration utility supports partial user impersonation, i.e. writing changes as per configured user mapping.
I’m beginning to consider moving an on-prem TFS 2012 installation to Visual Studio Online. So, one of the first things I started investigating was how we might export our content back out of VSO in the future if we ever decided we needed to. The more I’m looking, the less I’m finding. It seems there was a temporary time period when VSO first went GA that Microsoft offered that capability if you asked to have it done (http://www.visualstudio.com/en-us/news/2014-apr-3-vso.aspx). By implication, that would seem to mean that this isn’t something that is a planned feature of VSO.
Making a commitment to house all of my source and ALM data in a repository I’d effectively be barred from leaving doesn’t sound particularly appealing. Am I missing something, or does Microsoft really not have export capabilities on their VSO product roadmap? It would seem that this would be a show-stopper for many organizations from coming onto VSO, which is a perfect application to put into the cloud IMHO.
For code you can use Git. Even if you start with TFVC, you can use Git-TF. Clone with the --deep parameter to get the full history in a new Git repo, then push back to a new project (Git or TFVC).
For work items the TEAM tab in Microsoft Excel is a very capable export facility for work items, though you don't get links (other than parent child), or attachments.
In the original project, create a query that lists all your work items.
Open Excel, go to the TEAM tab and click 'New List', you should get the option to select your project and the query you just created.
In the Work Items tab select the 'Choose Columns' button and select all the columns you want to migrate.
If migrating to another TFS / VSO project, create that project, open another list in Excel connected to the new project.
Cut and paste all the work items from the original project list to the new project list (excluding the Id column).
Publish.
voilà.
You're right there's no good solution for this yet. However, if you're using Git as the source-control back-end (instead of TFVC), you can easily pull down the entire repo then push it up into any other source control server (non-VSO) with full history.
For TFVC source-control, or work items (or builds, test results, etc), things aren't so easy.
The answer is not black and white: with the TFS Client API you can connect to both platform and read/write as you please. It is not a trivial task, so someone has created tooling, like Brian says. Another option is using the open source TFS Integration Platform: it is complex but with some help you can do it.
What you really must consider and plan is the data model: moving from an ALM Platform to another is never trivial and the complexity lies in the difference of the underlying model and any customization you made.
As long as you do not customize you on-prem TFS, it is very doable, with a reasonable effort to move to VSO and back. In this context customize means: custom workitems fields, types or workflows, server-side plugins; shortly anything that requires code or schema change. Note that you can still customize builds as this is properly managed.
I expect to see more solutions arriving thanks to the new REST API, but it will take time before we see solid products.
So your original question has a positive answer (TFS on-prem -> VSO) using OpsHub, but know what you are doing and, as I write, it is practically a one way journey.
I'm really asking this on behalf of our sysadmins, so here goes:
We are moving from Serena to Team Foundation Server as our source code repository. It's a done deal (for better or worse) and I'm already aware of "no keyword expansion".
Anyway, the admins are planning to import source as version 1.0 (or whatever it uses for the first one) and forget about the history in Serena. However, it's a very large and fairly old codebase, and the loss of version history means losing a lot of information.
I have a fallback position of generating an ASCII version history files, one per module, and trying to attach them to each module in TFS. I'd much rather find a way to slam the version history in and preserve the version numbering (or something like it) once we're in TFS.
[Not answering the asked question] There's a CodePlex project out there that inserts keyword expansion to the TFS check-in process if you really want it. We use this with our SQL & PowerBuilder code and it seems to work well if you can accept a particular idiosyncrasy.
The project is Log Substitution Policy
There is a tool for migration PVCS source control data to TFS:
http://www.pvcs2tfs.com/
I'm asking this question because I haven't seen it documented anywhere.
We are using a combination of Team Foundation Server 2008 and Team Explorer 2005.
Is it possible to deploy a custom check-in policy that works in such an environment ?
Obviously, the custom check-in policy contains some code that must run on the client-side (in order to display help, etc.). So it should use the Microsoft.TeamFoundation.VersionControl.Client assembly that comes with Team Explorer 2005.
But, my sense tells me that, in order to be effective, a check-in policy should be enforced on the server itself (for example, to support checking-in changes from the command-line or using the raw Web Services API). So, there, it would have to run against the Microsoft.TeamFoundation.VersionControl.Client that comes with Team Foundation Server 2008.
So, is it possible to build a single custom check-in policy that takes the most recent version the Microsoft.TeamFoundation.VersionControl.Client assembly (2005 on the client and 2008 on the server)?
Or do I have to build two custom check-in policies, one for the client and one for the server ? Would that even work ?
Or do custom check-in policies only ever exist on the client side ?
The custom check-in policies only exist at client-side, and will only be evaluated client-side. If the DLL is missing on the client computer, TFS will complain, but provide a dialog that allows the user to override the error and check in anyways.
No, it's not required. However, it makes things much easier. Using the latest Power Tools you can store check-in policies in source control and have them deployed for "free."
A walkthru with screenshots is on Brian's blog:
....Since the day we introduced those features, customers have asked for a way to distribute custom components like these to clients rather than having to manually install them. Well, I'm happy to say that this new release of the Power Tools does just that!
Due to the fact that downloading custom components and running them on clients can be dangerous, there's a fair amount of care taken and some configuration necessary to enable it. Custom components for a Team Project are checked in to a new "special" folder called $//TeamProjectConfiguration. Let me show you a few screen shots and that will help walk you through how this works....