I've been doing some tests, taking my code from git to TFS, using git-tf. Everything worked pretty much ok, except TFS thinks almost all my files are binary (discovered while finding the answer to this question). Actually, all UTF8 or UTF16 files are detected correctly, but those with an unspecified encoding (.cpp and .h files, mostly) are detected as binary.
Is there a way (some setting, or anything else) to convert from git to TFS and keep the correct encoding? Or, probably less ideal, to change the encoding of all the wrongly encoded ones in TFS?
If you have not set the type of a file, Git will determine it automatically and may treat as binary. With the .gitattributes file you can override its decision.
Tyr to add the diff attribute in the .gitattributes file:
*.cpp -diff
*.h -diff
Related
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.
I'm currently evaluating PlastiSCM. One of our evaluation tasks is to test migration from our SVN repository to Plastic. We want to migrate our trunk only since the branch structure and information is somewhat broken.
I was able to migrate to git with git svn. I fast exported the git repo with -C -M parameters. The import into PlasticSCM succeeded. However, when checking out \master on the imported Plastic Repo, the client complains about missing files. These files don't show up in the "Items" list in the Client.
The filenames which have issues contain octal escape sequences. It turned out that these file names have got german umlaute (ä, ö, ü) in them. I was testing git fast import of the exported stream. Git is able to handle theses filenames correctly.
After some digging I found this aged thread: Fast export/import issues. I've linked to a post telling about the octal coding issue. The thread is actually adressing TFS conversion issues in general.
One author claims to have a script which recodes octal coded characters into an encoding which can be read by PlasticSCM fast import. However, the script is not provided.
Has anyone encountered this problem as well? How could a solution look like? I can't imagine I'm the only one having this problem, especially because Plastic is developed in Spain where non-english characters should encounter quite frequently. I wonder whether this issues is known and tracked by the Plastic SCM development team.
We have an ASP.NET MVC project that we want to create a publish package from during an automated build. The build is using the unmodified default template with Arguments /p:DeployOnBuild=True /p:CreatePackageOnPublish=True.
If I do a WebDeploy directly to a server it is working fine (if I change /p:CreatePackageOnPublish to false) but I would prefer to just create a package that I can deploy during a Lab build.
The error message looks like this:
TF270002: An error occurred copying files from 'C:\Builds\19\Binaries'
to '\nas\Build\Drop\MyProject\MyProject_Development.Test\20120209.1'.
Details: The specified path, file name, or both are too long. The
fully qualified file name must be less than 260 characters, and the
directory name must be less than 248 characters.
The first part of the problem was the build folder path was too long (274 characters) but after changing the working directory from $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath) to $(SystemDrive)\Builds\$(BuildDefinitionId) it's down to 230 characters as the longest path so it should be ok.
The problem now seems to be the path in the drop folder, even though it's root path is not that long by itself \\nas\Build\Drop\MyProject, the build name and Build Number Format quickly adds to the length MyProject_Development.Test\MyProject_Development.Test_20120208.1. After that all them nested paths create really deep folder structures _PublishedWebsites\MyProject.Web_Package\Archive\Content\C_C\Builds\19\Sources\MyProject\Source\MyProject.Web\obj\Debug\Package\PackageTmp\Content\ui-lightness\Images\ui-bg_diagonals-thick_18_b81900_40x40.png.
So is there any way to get around this problem? I shortened the build number format from $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r) to $(Date:yyyyMMdd)$(Rev:.r) to save a few characters but it's not enough. I guess we could shorten the build name a bit but it would break the naming convention used (Ok, that would not be a really big problem but it would be annoying!) and still it would feel like a short term solution.
What else is there to do?
The short answer is the path length limitation is really annoying, and you're going to have to spend some (more) time tweaking your file/folder structure to make this work.
For example instead of \nas\Build\Drop\MyProject, just do \nas\Build\Drop (or \nas\Builds) since the project name is also in the build name.
Flatten the folder structure in your projects (do you really need a Source folder under MyProject?).
Also, go vote for the UserVoice suggestion for the TFS team to fix the path length limitations: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation
I know the question is old, but I faced the same problem and I devised to solution to this, although it errs more on the preventing the problem from ever occurring rather than fixing the existing path length condition. It can then be applied once the issue has been - manually - resolved.
Please note that it applies to TFS under git. A similar approach could be devised for TFSVC, although it would have to be run after the code is merged.
Essentially, it's a short script to be run as part of the PR build. It enforces that no file added or modified has a path longer than the one you allow.
It is described in this blog post
.dproj files are essential for Delphi projects, so they have to be under version control.
These files are controlled by the IDE and also contain some information that is frequently changed, but totally irrelevant for version control.
For example: I change the start parameters of the application frequently (several times a day), but don't want to accidently commit the project file if only the part dealing with the start parameters has changed.
So how to deal with this situation?
A clean solution would be to take the file apart, but that isn't possible with the Delphi IDE AFAIK.
Can you ignore a specific part of a file?
We're using Subversion at the moment, but may migrate to Git soon.
In our case, it's rare for a developer to make a meaningful change to the .bdsproj, .dpr, .res files. So we reject the commit (pre-commit hook in subversion) unless special tags: [add project file] or [add res file] are present in the commit comment. This prevents "frivilous" changes to those files.
SVN/git cannot "know" which bits of the file are important, and translating what is important for you to commit or not into file "bits" would be difficult (especially when you don't know exactly how the information is structured within it). The most practical solution is to check the changes that have been made to the file and decide whether to commit them or not to the repository.
You can decide which bits of the file you want to commit with git. This is not, however, the automated process you seem to be looking for.
For the specific case of startparameters: the DDevExtentions plugin of the well known Andreas Hausladen allow for the start parameters be stored separetely of dproj file. See more details about DDevExtensions on his site.
EDIT: If I remember correctly, this feature was created just because he had that exact problem with start parameters and version control.
I would not save the .dproj files directly in version control, but rather provide a default file which should be renamed by the user to get the flawed Delphi working.
Use the --assume-unchanged option on git update-index <file> as described here and stackoverflow/what-is-assume-unchanged.
You could make simple aliases for the those who need it made simple.
We're using MS Visual Studio 2008.
TFS seems to take into account the creation date of a file or something, to determine whether the files should be committed.
Is it possible to make TFS test just on the filename and content?
I check out an xml or txt file
I copy the content
I open notepad and paste
I save the file using the same name, and confirm the overwrite
I commit: TFS by default selects the file for committing
Although the name nor the content has changed.
Our concrete use case:
We nightly run a script that generates xml files (overwriting existing files) and commits them.
We would like to commit only the ones that actually changed to keep the history clean.
Thanks in advance!
Jan
When you actually perform the check-in of the file, have a look at the changeset that actually is created in the history view. Normally TFS will check the contents of the files uploaded and will only include a file in the changeset if the MD5 hash of the file is different to the last version that was in version control.
Is this not what you see? Do you have multiple versions of the same file that are identical in content? If so - what extension do the files have? .XML or something else?
Take a look at the tfpt scripts. I think the following is what you are looking for:
TFPT.exe uu /r
The UU is Undo Unchanged and the /r is the recursive flag.
Take a look here: http://blogs.msdn.com/buckh/archive/2005/11/16/493401.aspx
Like Martin said, MD5 should be the only thing that matters.* Copy/pasting text into notepad is not necessarily a no-op. Common differences I've seen:
8-bit codepage -> UTF8, or vice versa
plain UTF8 -> UTF8 with BOM, or vice versa
trailing newline -> no trailing newline, or vice versa
Your XML generation script may exhibit one or more of the same issues. It might also be affected by things specific to XML serialization, e.g., writing the same objects in a different order.
*Exception: if the pending changes on the item include "merge" then it'll always show up in the history -- regardless of contents -- so that merge tracking stays in sync.