We're running TFS 2008 SP1, which has been upgraded all way from TFS 2005 Beta.
Since the old 2005 days we've had this project, lets call it Project A, that we now want to get rid of/destroy. However, this certain folders from this project have been branched off onto another project, Project B, that's currently in use and we definitely don't want to impact it.
So my question is, if we destroy Project A can it have a domino effect and destroy stuff in Project B or have any other adverse affect that we might not have considered?
I've done some testing in test environments for this and it seems to be fine but since we have no users in the test environment I thought it would a good idea to check with the experts out there before we do this in Production!
Also, is there any way of getting a fairly accurate or just a ball-park figure of the size of a Team Project within TFS 2008 ?
Thanks
We also have a database from the "beginning of time". I haven't seen any domino effects when doing that, but do have the sql and tfs patches in order for e.g. the "destroy isn't executed in transaction bug".
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.
We have upgraded our TFS from 2010 to 2013, and the same time moved the TFS and databases to new servers, with new names.
One of the very few annoying effects (Probably due to moving the TFS to a server with a new name) is that the build controller/agent from the old server is still visible in lists of available build controllers/agents, but is not visible in the admin gui for build configurations and therefore not possible to remove.
Does anyone have had the same experience and furthermore have a solution of how to remove the traces of old (and not used/wanted) build controllers/agents?
Kind regards,
J
Ok.
Sorry, I found the solution myself now after continue searching and yet again scanning through the microsofts documentation! :)
It's possible to disable and delete controllers and agents through the Manage Build Controllers in Visual Studio.
Also described here: http://msdn.microsoft.com/en-us/library/ee330987.aspx
Just make sure there is no builds in progress, but that's ofcourse also possible to handle through Manage Queues in Visual Studio.
Is there any way to move/migrate team projects of a Team project collection from one TFS server to another (both in TFS 2010 version). The destination Team Project collection contains a Team Project already and I want to move the source Team projects in to this particular team projects. So at the end I will have a Team Project which contains several projects in it. Is that possible? I want the history to be preserved as well.
If the above scenario is not possible, can I migrate Team projects from one server to another without going through the database backup-restore-TFS detach-attach process?
I thought of trying the TFSIntegration tool, but could see many people advised to avoid using this due to issues in it.
So if you have any information in accomplishing this, that would be great..
If you want all the history then you really only have 2 options:
TFS Integration platform - http://tfsintegration.codeplex.com/
Back up /restore the collection database - http://msdn.microsoft.com/en-us/library/dd936138.aspx#Backup
I would recommend moving the database. This sounds pretty onerous but is actually quite easy.
Good Luck!
TFS INTEGRATION PLATFORM used for integration.
A tool which helps a lot named "witAdminUi".
we have 2 dev teams, one team work on TFS2005 and the other team work on TFS2010.
it's the SAME project but one team is continue to work on .net framework1.1 project version and the other team work on the .net framework4.0 project version.
WE HAVE ONLY SOURCE CONTROL (NO WORKING ITEMS AND ETC...)
after we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
can check in can be done automatic to 2 TFS servers ?
I'd avoid splitting your code base accross 2 servers if possible. Once you've moved the code in to TFS 2010 I'd use branching to distinguish between the .net 1.1 version of the code and the .net 4 version.
Once you have the code in branches you can merge the code on a regular basis to keep the versions in step.
You need to think about what branching stratgy works best for your situation, read the guidance on codeplax to help you decide. Your branching strategy will depend largly on whether the .net 1.1 version of your code is being actively developed or if it's just in maintenance / bug fix mode.
If you're using VS 2003 to do the .net 1.1 development you can use the MSSCCI provider to give you basic TFS integration.
From your description it sounds like you already have two versions of this project in two separate TFS Servers. I agree with James that it's best not to split codebase across two version control systems, but sometimes we just end up in this type of situation.
How are you importing from TFS2005 to TFS2010?
This is an important question. TFS2010 does not have a way to import a single Team Project from one server to another. You can Import an entire TPC (Team Project Collection). I know of only two methods:
A) Seriously look at TIP (TFS Integration Platform). It's not perfect, but it is designed to do what you are looking for.
B) You can do a snapshot migration. Basically this means getting latest from VS2005, check in to VS2010 (wherever you want), then leave all prior history in VS2005.
If TIP doesn't work for you or is deemed too risky or missing critical info then find out if TFS2010 can import TFS2005 databases to migrate your TFS2005 Team Project Collection. If yes then make a copy of the TFS2005 Version Control databases, then import the entire Team Project Collection into TFS2010, then delete the other TFS2005 projects from this collection that aren't needed. You can call this your TFS2005 Archive Team Project Collection and keep the full fidelity version history on-hand if needed. I did a migration from TFS2008 to TFS2010 a couple times. It's non-trivial but doable.
Migration approaches:
Plan A: Migrate everything to TFS2010 and retire TFS2005 as soon as you can. You can archive 2005 or perhaps move it to a virtual machine if you feel it's essential to have available... but you really want to cut your admin work in half plus get 5 years worth of improvements by moving everything to TFS2010.
Plan B: Set up a system that allows you to integrate between the two servers until you can finally retire TFS2005. Stay in this situation only as long as absolutely necessary and upgrade whatever you need to unblock moving everything to TFS2010.
Q&A:
After we do the first import from TFS2005 to TFS2010 to TPC X, can we import after one week just the changes of the passed week?
A: It should be doable, but fidelity of import depends on how you are importing.
If you are doing a "snapshot migration" by checking in the latest version of VS2005 code into VS2010 then you can check out the first snapshot, repeat a new snapshot over the code, then merge the changes. The BIG drawback to snapshot migration process is that you lose all metadata in TFS2005 including change history, labels, checkin comments...
If you use TFS Integration Platform hopefully most content and metadata will transfer. The neat thing here is once you define the synchronization rules and run it once you can simply re-run the same migration with minor changes. Watch for how labels and changeset metadata gets transferred.
Can we do import (TFS2005 to TFS2010) to the same TPC X (already existing one) ?
TFS Integration
A: That shouldn't be a problem. TFS Integration Platform or checking in a "snapshot migration" can be targeted to any folder path. I assume there is no formal branch relationship established between the two codebases currently. Therefore I'd strongly recommend checking in the imported files into a separate folder, convert it to a branch (if not already done by import process), then establish whatever branching relationship makes sense to the existing TFS2010 project branch. If there is no shared code between these two projects then I'd keep their branches separated.
Can check in can be done automatic to 2 TFS servers?
A: That's the promise of TIP (the TFS Integration Platform). I personally had a rocky time trying to get it to migrate full source history from one TFS2010 Server to another, but big part of that problem was network issues traveling across 6,000+ miles and 3 firewalls.
Start by reading this blog and it's comments for a well balanced discussion of TIP and current limitations: TFS Integration Platform Updated (Mar ‘11)
Good Luck!
We've planned to move from Visual SourceSafe to TFS. For this purpose, we brought a new server machine with updated specs and TFS installed. The Visual SourceSafe machine still has its use in the environment as the TFS machine dedicated for a single project.
All the projects are there in Visual SourceSafe machine and are being managed since more than half decade. As I said there will be only one project which is going to be moved on TFS machine. What we required here is a complete and safe image of VSS Working Directory of the project in TFS machine because to Migrate from VSS to TFS you would have to installed Visual SourceSafe there on TFS machine.
What is the best practice to move your
VSS Working Directory (project) from
machine-to-machine. Is there a way to
avoid this step and we could directly
move VSS Working Directory to TFS?
Once the project working directory setup on TFS machine, we can use VSSConverter.exe utility to migrate from VSS to TFS. There is an GUI version of VSSConverter.exe utility which makes this more easier than doing this through command prompt.
A Team Project is successfully created with MSF for Agile Software Development on TFS machine. There was an issue in the beginning trying to create the Team Project which seems SharePoint services were unable to start. Finally, we ended up on some blog who mentioned if you installed SharePoint Services after TFS then you have to check the SharePoint Central Administration Services and change its port to default 17012.
This is what we could have done on TFS. Not sure, are we on the right route or not? The ask is not big move a single project from Visual SourceSafe which is an independent machine to TFS machine. But, it is because we all are new on TFS.
The expenses already made, a new server machine, Windows 2008 Server R2, and TFS which let no choice for us except learn and do it. I hope this will become a good experience all in the end but to make it good we have to put more efforts and build attitude to get through this.
I will be thankful if you guys could suggest us on this circumstances how should we plan and collaborate. The best can be this, all this transaction will not affect our productivity on project. We could deliver and managed our deadlines along with this showdown.
Thanks.
Have a Good Day!
POINT 1: It sounds like you have already had someone recommend that you migrate all your projects at one time. The reason they recommended it is because it is generally a good idea. If I were you, I would take a second look at migrating all the projects and using switching everyone to the MSSCCI provider for TFS. This will essentially let everyone continue to work just like they do now and with the same tools they use now but the code will be in TFS.
POINT 2: Spend a little time to make sure you want to use the MSF Agile process template. Not because there is anything wrong it with MSF (it's great!) but because it is hard to change templates once you get started. This is the time you want to do a little thinking about software process improvement and how you want the office workflow to function once you are all using the full Team Explorer client. My shop has been using the Scrum for Team System template and we love it. It is especially cool when you add on the Scrum Dashboard web site and the Scrum Sprint Monitor on a publicly visible screen.