I want to copy an entire TFS project to another project, e.g. MyProj to MyProjSev. Then I want to rollback MyProjSev to a changeset that corresponds to when the client stopped paying. Then I will make MyProjSev available, including the history of the source files, to the client for a period of time as part of the severance agreement. The access/security aspect I know. I can easily make a branch, but if the client views the branch from a TFS Explorer Client, then the history is not available. There are a couple of approaches that involve cloning the entire collection, and lacking an answer to this question here, I will use one of them.
https://stackoverflow.com/a/4918289/553593 [TFS admin detach the collection, back up SQL Server database, TFS admin attach collection, SQL Server restore database to new database name, then TFS admin attach the restored collection]
http://msdn.microsoft.com/en-us/library/ee349263(v=vs.100).aspx [Collection command with /clone]
New Information http://visualstudiogallery.msdn.microsoft.com/eb77e739-c98c-4e36-9ead-fa115b27fefe TFS Integration Tools was what finally worked for me. This 2012 release is a very nice product. It was easy to do a TFS to TFS transfer from my MyProj to the new MyProjSev that I created for client to access. Upon completion I simply did some rollbacks and set the security in the new project. It would have been easier if in TFS 2010 one can rename projects (can do in TFS 2012) Neither the TFSConfig Collection /clone nor the procedure described in MS Docs for Splitting a Team Projects Collection will work for this task. The issue is that even though one ends up with two collections, their projects have the same names, and that is not allowed (and in TFS 2010 you cannot rename projects).
The best option is to clone the collection as you suggested.
I answer my own question as described in New Information above in the text of the question. Note all this is specific to TFS 2010.
Related
My organization formerly used TFS, but has now upgraded to the latest version of ADOS 2020. There are several things that collections that were created after switching to Azure DevOps Server 2020 can do that still involve a process on our collections brought over from TFS, such as updating WITs. What is the process for making these collections ADOS ones? Do we have to just recreate them and data dump from one to another? If this is the case, how do we transfer all of the historical data on our work items and CI/CD pipelines?
We have experience using the query tool to import new projects into ADOS, but want to know if there is an easier process since it is TFS to ADOS and we want to save our data.
I have created a new app service on Azure, that i want to connect to an existing project on my TFS.
The problem is, when i choose Continuous Delivery -> Source and selects Visual Studio Team Service and selects the correct project, it says that there is "No repositories found".
What am i missing?
And as you can see, there should be a repository:
It looks to me like you are following the instruction for the new CD services that support Git only: https://www.visualstudio.com/en-us/docs/release/examples/azure/continuous-to-app-service
If you are still using TFVC you may need to follow the old 2013 instructions: https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-continuous-delivery-use-vso
If you want to move to Git to take advantage of this and other features then you can migrate using the Git-TFS tools on GitHub. Or even better, you can start from scratch and ditch binaries...
We are starting to use TFS2013 (we use svn still, but for a number of reasons we're putting new code on TFS).
I have a solution that contains a project with an EF database model and I would like to share it with a different solution (to be more specific: there is a client website solution and a separate one for backend).
On SVN I would have created svn externals - I would be able to share the code easily and if I branched, the shared project would have a nice copy on branch as well. Moreover, both projects would have the most up-to-date version of the db model, which suits me perfectly.
TFS 2013 seems to push be pushing towards NuGets. That means, that if I create a nuget package of the db project:
I will have to update the db projec separately each time there is a db change, release it and then update all projects that use it
If I branch, I'll probably have to create a different nuget package for the branched version and amend the nuget reference on merge
It pollutes the nuget repo with things that are not exactly worth a repository (in case of a DB model, you want to have the latest possible version because a website will probably break if you don't, no point for versioning so that the build doesn't break)
I spent some time trying to find a suitable solution, but the best idea I found is just referencing the project from a different solution - the problem with it is, I would have to make the root folder for the build be higher than just the solution and that would add several more projects that I don't need. Another idea is referencing by branching, which was good for TFS 2010 with multiple projects, but I can't fit it into my scenario (we have a single 'Main' node where we put all solutions).
So, how would you share a DB project on TFS 2013?
I have been working with a TFS project that supports copying build output to source control. If I open the build definition, this is under "Build Defaults". There is an option to copy build output to a source control folder.
I have just installed TFS Server 2013 (with update 2) and I want to use this feature with a new Team Project. However, if I create new build in VS 2012 or VS 2013 on the new server, I am not given the option to copy build output to source control. What gives?
I am not looking for a workaround, I want to know what to change so that my server acts like the first one I described. Thanks!
Screenshots of what I'm talking about: http://imgur.com/a/mhDNQ
This was a feature that was temporarily present in TFS, but I believe has since been removed. If I recall it was put in there specifically to support the cloud-hosted elastic build servers which didn't have access to network shares to drop the builds in.
Most people recommend against putting your build outputs into TFS. The best approach is to publish them to a NuGet feed.
In any case if you want to put your build outputs into TFS (or a NuGet feed) you'll have to modify the build workflow to do that yourself.
Open a new build definition > process.
Under template select new and you should be able to choose project and folder. Find your original template and link it. Your option should appear.
In TFS 2013 this has changed to be "store drops in TFS". When you select this option the drop I'd stored in a new inversioned store that you can access.
While you can easily get the files out as indecision or zips the built in tools like release management do not support it yet. I would recommend that you use this option but publish your assets to a nugget repository.
If your TFS is available online (VSO or https) then you can use MyGet to dynamically load the nugget packages that you are publish and make them available on a feed.
http://docs.myget.org/docs/how-to/use-tfs-online-git-with-myget-build-services
I am involved in some TFS setup at my new job and one of my tasks is to setup the location of the common framework assemblies in TFS so that the other projects can reference them. The only way I can think of is to branch the assemblies from the framework folder into all of the other projects. The issue with this is that anytime I want to update all of the projects with the new assemblies I need to merge each branch one at a time. Is there not a way to merge all at once?
I mentioned that we should use NuGet but that would rely on the developer doing a get on the new version, they want to push it to the project to ensure that it is being used...
Any advice would be much appreciated!
NuGet is the right way to do it. Make your Framework build publish your NuGet package to a local NuGet Server from where is it is referenced by everyone. This way, when you upgrade framework, everyone will get it and you don't have to push it.
After doing lots of looking around I believe the answer to the problem is here in these two articles:
http://geekswithblogs.net/jakob/archive/2009/03/05/implementing-dependency-replication-with-tfs-team-build.aspx
http://geekswithblogs.net/jakob/archive/2010/12/08/dependency-replication-with-tfs-2010-build.aspx
I'll need to adapt some of the ideas within to TFS 2012.