I have migrated some projects from TFS to Visual Studio Team Services (formerly Visual Studio Online) following these steps. After that I realized that I have an extra partition (with the same size and free space as the Windows partition) with a lot of folders and files created during de migration. Most of folders and files are empty. Only some of them have source files (migrated files).
Folder name examples: i10_7, i10_null, i11_7, i11_null, i20_14, i20_null, i21_14, i21_null,...
File name examples: 1457433532708.txt, 1457433533840.txt, 1457433534475.txt, 1457433534476.txt,...
So is it safe to delete the files? How can I remove this partition?
Yes, the OpsHub Visual Studio Migration Utility creates the Virtual Drive(s) to map to the folder containing TFS Workspace. This is done to overcome the 256 character in file path limit of the operating system.
Whilst the migration is running, DO NOT delete these folders/drive. Once, the migration is complete, the drive is automatically un-mapped. (You can then delete the contents if you wish to do so)
Related
We currently use TFS 2010 for controlling some of our .NET projects.
I'd like to know whether it's possible to provide some kind of versioning within TFS for a specific folder on a network share for example.
The idea being is to control release packages (zips) for every release we do. As this bit is done by some other person (not technical and he doesn't use Visual Studio or any tech tool), it'd be great to streamline the process of versioning the zip files for every release.
Technically speaking:
We've setup this folder \servername\releasezips and every time I drop a file named release.zip, it would automatically commit (push) this file to the TFS server (no comments needed) and furthermore, once the file contents change (meaning that someone dropped another version of the file in there), the system would again push the file to TFS, but with a following version.
Is this possible somehow? I've seen somewhere that I could programatically have some extra control over TFS, using REST API.
Thanks in advance!
Thanks for your tips, Daniel and PatrickLu-MSFT.
As I said, I did want something straighforward, some kind of control similar to what box.com provides, where you associate a local folder on your machine with the cloud. So, once you drop files in the local folder, the small box client synchronizes it along with the cloud. If access the box.com, I can see the different versions of that specific file.
So what I did was, I've created a small .NET app to monitor the folder and any new files dropped in there would get checked in to our TFS server, by using the tf command line (of course ignoring work items or comments).
So, progamatically within the .NET app, it builds up the tf required commands for processing and versioning the recently dropped files and therefore, executes them.
By the way, I could have used the Team Foundation API in order to do the same job, but it would demand way more effort.
Cheers
According to your description, you want to commit/check in files during the build/release pipeline.
It's not a recommend way to check-in generated build files and modify source code during a build pipeline. If you really want to do this, you could edit the build workspace files and use tf commands in custom activity and call the powershell eq:
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 1x.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Another way is installing TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for more details: PowerShell and TFS: The Basics and Beyond
For version the dropped files, you could take a look this similar question: TFS Build Copy to Versioned Folder
Basically, you have to customize build definition with custom activity and based on build.buildnumber variable to generate/create .zip file.
I'm new with source control but since we are more than one developer in our company I started introducing git with Visual Studio 2013 Express and the Team Foundation Server. Now when I create a new project and add it to source control it seems that sometimes one random cs source file in the project is excluded from version control. In the Solution Explorer there is no check-in icon infront of the file. Also there is no other icon infront of it and if i publish the repository to the server the file isn't there.
I have no idea why the file is excluded and how to include it.
Is there any way to show linked files after a VSS to TFS migration? Additionally, how do you link files in Visual Studio 2013?
As Edward Thomson wrote, there is no such thing as linked files. Excerpt from How To: Migrate Source Code to Team Foundation Server from Visual Source Safe.
The main issues that you are likely to encounter are due to some differences in the way TFS handles version control in comparison to VSS. For example, because TFS does not support sharing of files, shared files are migrated by copying the version of the file at the time sharing began to a destination folder. Also, because branching in VSS uses sharing, the migration of a branched file results in the file being copied to the destination folder in TFS source control. As TFS does not support pinning, to help you locate items in TFS source control that were previously pinned in your VSS database, the VSSConverter tool labels any file that was pinned with the “PINNED” label.
With the new Visual Studio 2012 there is this so called directory "PublishProfies" which is located under the "Properties" folder.
Every time we create a publish profile for a web application, it is stored into that directory, then automatically added to the project and the source control (we are using TFS 2012). For our development environment this is not a desired behaviour. We would like each developer's machine to be able to have it's own publish profiles.
Is it possible to somehow tell the Visual Studio to store these profiles elsewhere, or at least not to add them to the project structure and source control respectfully?
I have some source code and other artifacts such as images that are not created in Visual Studio 2010. I want to put them into TFS 2010 version control, how can I do this?
TFS does not care what the format of your files is; you can use TFS to store any type of file - whether it was created in Visual Studio or any other program. This is true of all TFS versions.
The comments already somewhat address how to add a file to Source Control using Source Control Explorer; Once you have a workspace mapping, copy files or folders into a mapped folder in your workspace, right-cick on the folder you added the file to in Source Contol Explorer and select the option to Add Items to Folder; This will launch a wizard that you can use to let TFS know that you want to add the selected file(s) or folder(s) to source control - it can be any file on your computer.
After the files are added, check-in yor changes by right-clicking on the file in Source Control Explorer or by using the Pending Changes window (View menu -> Other Windows -> Pending Changes). Almost every source control operation in TFS is a 2-phase commit that involves first letting TFS know what you want to do (like add or delete a file) and then actually committing that change with a check-in.
You can also perform these steps using TF.exe from the command line or the Shell Integration Feature that is installed seperately with Team Foundation Server Power Tools (TFPT). Please note that whilst you can list and view the contents of files in TFS using the Web Access user interface, you cannot check-in or check-out files using that interface. Also, you will not be able to perform any source control changes without Visual Studio or at least a free version of it, named Team Explorer.
The only qualities of files that matter to the behavior of TFS are if the file is a mergable file type or not and what the encoding of the file is; however, in most cases the default setings in TFS will be fine for you. Mergeable file types are files that TFS will enable merging for; Examples of mergable file types are text files; Non-mergeable file types are file types that you would not want to merge, like pictures or Microsoft Excel files. You can read more about Managing File Types on the Microsoft site.