We've decided to go with a different template for our team project and want to move all of source under that team project. We are not concerned with migrating work items, but we would like to keep the version history of the source files, if possible. I tried the TFS to TFS migration tool on code plex and it seems to only move the most recent version of each source file over.
We are on TFS 2008 and the team projects are on the same server.
EDIT: It looks like the move function may work. I've seen some concerns posted about whether or not this moves all the history for a given file.
If you do a move from within TFS, that should register as just another action to be saved in the history. Your other history should be kept intact, even when moving across projects.
Related
In the past, we seem to have created a TFS repository that was not part of a project. It seems that this is no longer supported by TFS in recent versions.
After updating TFS 2013 to 2015 and then 2017 we did not immediately notice the problem, but looking in the Collection Management screen on the web portal shows that the "Project" (which is not a project) is marked in a "Deleting" status.
The Microsoft page about this says that if you want to keep the code, no action needs to be taken. That "Deleting" status worries me however.
Is there any way to add an existing repo to a project? I can create a new project. I can add a new repo to a project. Can I add an existing repo to a project?
Alternatively, can I "Un-Deleting" that repo somehow?
That page have described this very clear:
Otherwise, no action is required. Placeholder team projects are
hidden in Web Access and Team Explorer in Visual Studio. Therefore,
they have no significant effect on day-to-day usage. As with any
other deleted item in Version Control, you can still access the
corresponding project in Source Control Explorer if the Show/Hide
Deleted Items button is enabled.
As you said, Placeholder team projects are not real team projects. When you delete a real team project, it will permanently removes data associated with that project from the database. You cannot recover it later.
They are just as deleted folders/items in TFS, you could undelete them in Visual Studio Source Control. Just select the deleted folders and right click it select undelete , and check in pending changes. Then you could get/download all files in the repo to local. Create a new team project, add files to the project, finally delete the particular placeholder project.
Since there is no way to import deleted files to either a existing project or a new project. Above is a safety workaround, the only disadvantage is it will lose the source control history of those folders. Otherwise, you could also take no action as the page suggested, the Placeholder team project will not be deleted. If you encounter any problem about this, you could contact the TFS support.
I started work a lone developer last year and I found VSS is no longer a good option for source control so I decided to use TFS 2010 instead.
I have had to learn everything from a book - of which there are few.
I am currently creating a new build and in my workspaces I see a have 4. I want to delete one of them and rename another.
However I do not know what the consequences of doing this are. If I delete a workspace, will that remove the associated files under source control? How do I check which files these are? What happens if I change a status from active to cloaked?
As you can see, I am a beginner in all this.
Workspaces are only a mapping from SourceSontrol folders onto your local file system. Also workspace contains information about versions of the files you have locally, so when you hit 'Get Latest Version' only recent changes are sent from server to you, not the whole files. Information on what files are checked out is stored in workspace too, so if you have pending changes in the workspace and delete it then there'll be a bit of a challenge to check these changes in. Renaming of the workspace will not break anything as far as I know.
Article An introduction to TFS Workspaces may be interesting to you.
Like the others have said, the workspace only says what local files you have checked out, and the status, etc. Workspaces are pretty granulal (i.e. per user and per machine) so you could have mutliple workspaces with the same username in the same project. E.g. if you have a copy of Visual Studio at work and one at home, you could have different files checked out and you wouldn't run into any conflicts like you would have in VSS or something based on VSS Like like VSSConnect.
We've had a couple of people leave out project and have had to go in and remove their workspaces after the fact. This hasn't been a big deal in terms of any code losses but if you don't have access to the machine anymore you will have to use the TFS tools.
Try TFS Sidekicks, it provides a nice GUI to manage all the nitty-gritty back-end stuff in TFS
My team is moving to TFS and we are currently testing migration from VSS. The VSS Converter requires all TFS projects to be created prior to conversion. We have upwards of 30 projects and it is time consuming to create these.
Is there any way to refresh the source control portion of our projects between tests (returning them to their original blank state) while leaving the projects intact, thereby allowing us to run multiple conversion tests without having to recreate our project collection and projects every time?
[Edit]
To answer John's question below: When creating a Team Project TFS, by default, creates an empty source control folder by the same name and associates it with that Team Project. The conversion file requires that source control folder to be available.
I'm going to make some assumptions.
you're using TFS 2008 or 2010
you're not afraid of the command
line :-)
I think in this scenario the "tf destroy" command is going to be your friend.
e.g. "tf destroy $/TeamProject1/FolderToBeWiped"
You could easily write a script that wipes all of your existing folders in source control. As a word of caution, DO NOT do "tf destroy $/" as this will take out the Source Control part of the team project(s) and you'll need to create it (them) again.
As a follow-up, I finally found a way to automatically create the requisite projects. Essentially the process is to drop and recreate the collection, then generate the projects from your xml mapping file. If anyone is interested I blogged it here
http://irwinj.blogspot.com/2011/05/tfsautomated-project-creation.html
Our situation:
In TFS 2010 + VS 2010 environment, we need to move source code and work items from old project to new project (new project is just for renaming and restructuring purposes, they all under one project collection).
We used TF.exe command line utility moved source code, it's good and carried history and links (changeset links to original bugs/tasks). We are happy about it.
Trouble appears when We tried to use TFS integration tool (MS recommendation) to move work items, it only carries forward attachments but no links. We need those links to link to our changeset. it's very important to us.
As I dig deeper, I know this "move" is not "real move" but creating new ID and copy the old information. Just wonder is there a way to do the move and still keep our links in bugs and tasks.
Thanks a lot
I got the following link from Link.
Have you looked at Hemi - Hemi is a tool that helps you move work items from one team project to another in Team Foundation Server.?
I think this is TF2008 - so you may be able to update the source to VS2010
I'm a consultant whose client runs a TFS 2005 repository. I manage my own source code in TFS and deliver my releases to their TFS. My source code is around 20,000 files that I maintain.
My normal process:
Detach my solution from my TFS
Connect to their TFS
Checkout the entire project
Overwrite my project files with
theirs
Check everything back in
Click the add button and add any new
files that have been added
Check everything in
Open the solution file and bind it
to TFS
Check everything back in
The main problem I'm seeing with this approach is if I delete a file on my end, I don't have a way to reflect that change.
I'm also not interested in synchronizing tools because I don't want to synch every checkin, just the current state.
Is there a way I can do this better?
What about maintaining parallel .sln and .proj files with the different bindings? Do they change often?
I think you can maintain change history by using the TFPT ONLINE command from the Team Foundation Power Tools.
Open SLN_A
Make changes (VS auto-checks out against TFS_A)
Before checkin on TFS_A, run TFPT ONLINE against TFS_B. This should pick up adds, edits, deletes.
Checkin SLN_A on TFS_A.
Checkin SLN_B on TFS_B.
Only problem with this might be that the SLN_A checkin could screw up the SLN_B pending changes b/c the files will be returned to read-only. Not sure.
Why do you need to maintain a parallel TFS? Seems like you ought to be working directly against their TFS, either on a branch, via the Proxy, or both.
Have you looked at TimelyMigration? (No affiliation and I've never had need to use it)
TFS to TFS migration