The Eclipse compare view shows four properties for files stored in RTC:
Executable
MIME Type
Line Delimiter
Character Encoding
I know how to change the first three of them using the Eclipse or the Visual Studio client, but how can I change the “Character Encoding”?
This thread mentions:
To change the file's encoding on server side, you need to load the file into an Eclipse project, then right-click the file and select "Properties".
In the Properties, set the file encoding to "UTF-8".
Then you need to make slightly change on the file content, so you can check-in/deliver the file from Pending Changes.
After that if you open the repository files from the workspace or stream and check it properties, you can see the file encoding is updated.
If you are using Visual Studio client, there's no direct way to modify a single file's properties. You need to edit magic.properties file to change the file's encoding on client side first, then modify the file and check-in to server side.
Note, as mentioned in this thread:
Text encoding isn't handled by source control. It's however the client is set to interpret the file.
For Eclipse clients, there are preferences for the encoding that users can set for each type of file. Eclipse can also set the encoding per project. So the change you're making in the GUI isn't being shared with source control.
Related
The way we use TFS is that in our development tool we export all classes of the project into one XML and manually upload that XML as the new version to our TFS project. However sometimes the export process includes classes that must not be in that export.
Can TFS validate the content of the upload and give a warning that the file contains illegal strings, such as "class this.that.shared.never_include_this_in_exports()"?
Can TFS validate file content and reject / give warning?
AFAIK, I do not think TFS supports validate file content feature when we upload it to the repo.
For TFS, whether it is a centralized TFVC or a distributed git, TFS only tracks and controls the file itself, and does not provide verification of the syntax in the file. This should be a function of our compiler. It should not be a function of a version control tool.
So we need to use other tools locally to verify whether there are any errors in our XML, or, as Daniel said, to verify whether the file is correct through CI.
I'm doing some tests with TFS prior to moving all of our source there.
Right now, I've created a very simple solution and I've set two workspaces, one local and one in the server.
With both workspaces on the last version, I've made some changes in the server workspace and checked them in. Then, I've made some other changes in the local workspace and I've tried to check them in too. Of course, there is a conflict, but I only get the option to keep the local changes or take the version from the server. I would expect to see an option to merge the different changes.
I'm pretty sure I've seen the option to merge before, in some other tests I did some time ago...
Any solutions? Am I doing something wrong?
UPDATE:
I've clicked in the "Annotate" button and it tells me it can't be done because the file TestApp.cpp is a binary file (Error TF206000). Maybe I should add that I've moved the files from git via git-tf. However, the file on my computer seems fine, ANSI-coded, with CRLF line endings, and no strange looking characters in notepad++, or any other editor I've opened it in...
UPDATE 2:
Answering MartW's comment: The file on the server looks the same as on my PC. Well, there seems to be some encoding issue, since the accents are not shown properly. Also, it doesn't let me annotate the file on the server through the browser, with this error: "Valid values are between 0 and 65535, inclusive. Parameter name: codepage".
I've checked through the versions, and I can annotate the first one where the file appears. All the rest give the same error.
Whether merging or not is available for a particular file type is dependant on the file extension, and controllable via the TFS Source Collection settings.
In TFS 2013, this can be accessed from within Visual Studio and selecting Team => Team Project Collection Settings => Source Control. You'll see a list of various file types and associated extensions, along with whether file merging is enabled for those types. CPP files are under the C++ section and should say Enabled - perhaps this is Disabled in your setup?
OK, I think I found it. Apparently, TFS has decided that all my files are binary files. By going to the Source Code Explorer, selecting the file, opening the context menu and selecting Advanced|Properties, I've been able to change the encoding (actually, if I tell it to auto-detect it, it does it just fine) and now I can merge...
Now, I have to find how to change the encoding of all the files (well, just text files) at once.
In our project solution we done the changes in 5 files (only content change) and the change set number is NNNNN, we want to download those 5 files only. We can get entire solution files upto this change set. Due to content change we want those files only instead of getting all other files like dll or *.CS files.
In other source control the view history displays the affected files, there is a provision to export those files into folder rather than entire solution.
You could write a little PowerShell/.Net code to do this or you can use the TFS Power Tools. There is a command line tfpt.exe and you can use the getcs flag
tfpt getcs /changeset:12
There is a decent write up of the process here
This is more of a hypothetical question as I am sure this is not a very good way to do things.
Say I have an SSIS package, under source control in TFS, that needs to read and modify some files, say a csv. how does it handle modifying the csv if the csv is also under source control in TFS?
i don't have a complete understanding of how it works, but i assume the csv would be under write protection until it is checked out. Does the ssis package just error out when attempting to write to a write protected file? Having to modify the SSIS packages to somehow get around the write protection would require a lot of work as all the these packages are already written and being added to source control now. alternatively, I assume there is some kind of settings you can do in TFS to turn off write protection on your local copy or automatically check out a file if it is being modified.
is the real solution to just keep the input and output files from the SSIS package outside of source control (as there is probably questionable justification for them to be there in the first place?)
TFS is integrated into Visual Studio. When you edit a package, VS checks it out of TFS for you and you can use Visual Studio's interface to check it back in.
In VS, Tools/Options/Source Control sets up the source control provider. File/Source Control is where you manage the connection to the project.
If you change your workspace over to a local workspace the read only attribute is removed for all files.
If however you need to edit the file in a normal workspace why I'd it under source control at all? A better way would to have separate files for DataIn, DataOut, and DataCompare. You should have DatIn and DataCompare under source control, but DataOut should be generated.
It is not recommended to have any generated files under source control.
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.