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.
Related
I know I can look at the "Source Control - Team Foundation" output in the Output window but it's hard to tell where the results from the current request begin and the last request ended sometimes, and any files that I want to compare that are in the list I have to go look up.
In the past when I used subversion, I had a tool (I think tortoise) that did an awesome job showing me all the files that were changed and I could click directly on them to compare with latest version. I would often use this to do quick code reviews, and it made it much easier to make sure I wasn't about to get an updated project file that had been improperly merged.
Are there any extensions/plugins or anything that can help with this for TFS when getting latest?
Unfortunately there isn't such a tool can exactly achieve that, there is a user voice submitted here, and it's ARCHIVED.
Based on my experience, the best thing to do is a folder comparison before you get the latest version. In Source Control Explorer, you can compare the differences between two server folders, two local folders, or a server folder and a local folder. Right click on the target folder and select Compare. Read more here.
To see the changes block you can introduce the third compare tools. (e.g BeyondCompare, ExamDiff, Code Compare etc, you can reference my answer in another thread : Visual Studio TFVC Merge Lines Misaligned). In short you can get the change list from Output window, then compare each file accordingly.
Besides, you can also try using the Tf Command Line Utility and the Visual Studio extension Diff All Files for VS2013. Reference this thread for details : TFS Shortcut to do a diff on all modified files with latest version
On one of our builds we are kicking off some automated process which is checking out and checking in some files automatically.
This all works rather well, but at this time we are running the checkin command which looks like the following
tf.exe checkin /force /comment:"foo" /noprompt /bypass /override:"bar"
All of the files with a Pending status will get checked in.
I'd like to make this script a bit more specific and only checkin the files (2 in total) which we actually change during the build, so we know for sure no files will get checked in 'by accident'.
I've already seen we can specify a single filename with the checkin command, but doing so we will get 2 different changesets in TFS, instead of 1. We would really like to have 1 changeset, containing both changed files as the changes belong to eachother.
Any ideas on how to approach this?
Minor addition / Short term solution
For the moment I've solved our 'problem' by specifying the folder where our modified files are located, which kind of looks like this
tf.exe checkin "/my/folder/location/" /recurse /force /comment:"foo" /noprompt /bypass /override:"bar"
Note the folder location and the /recurse parameter added.
You simply separate the files by spaces:
tf.exe checkin file1.ext file2.ext /force /Comment:"foo" /noprompt /bypass /override:"bar"
The documentation is not clear about this point but it might be a general specification of an itemspec that it can be multiple items.
See similar question about checkout: Is there a way to check-out multiple files from various folders in TFS in a single operation
As mentioned by others you might run into problems with the command line being longer than the system supports, in which case you might need to look at other solutions.
cmd.exe has a limit on how long a command can be. Using the version control API, or simply 'tf checkin /i' (no arguments) is likely to be a better choice than passing lots of long filenames.
It's normal if a file becomes automatically checked out due to a change, and if ultimately the contents of the file are changed back to it's original state. At that point you would see the message about identical contents upon comparison. You could also use tfpt uu /noget /r * command to ignore Files which are identical to the originals. You'll need to have TFS Power Tools installed for this to work. Note: there is no TFS Power tool 2017.
For more details please refer below two links:
Visual Studio TFS shows unchanged files in the list of pending changes
Can TFS Pending Changes show files that are truly changed like SourceGear Vault?
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 need to bulk-check-out of all our .html files.
(to do a masse edit-replace from the command-line, and check them all back).
This is just a one time thing. I see a lot of threads on how to exclude files types but at project inception and definition level, like
Team => Team Project Collection Settings => Source Control File Types
or for TFS 2012 the .tfignore file.
But..
1) This seems to be for permanent exclusion at the project level. I don't want to touch the overall Source Control settings, colleagues work with all these other files types I need excluded.
2) These filters are all defined by what you exclude. But it would be much easier in that case, to define what you want to include (here .html files), so in essence, to say include 'A', instead of having to say exclude 'B', exclude 'C', exclude '...' going after the whole alphabet.
Thank you
For a bulk checkout, you can use tf checkout.
Open a command prompt with the current path within your local workspace and issue this command to check out all .html files:
tf checkout *.html /recursive
If you want to limit the checkout to part of the source tree, specify that in the itemspec:
tf checkout $ProjectCollection/Trunk/Project/*.html /recursive
If you are using TFS 2012 or newer, just make sure you are using a local workspace and you don't need to explicitly check-out anything. TFS will automatically detect local changes and put them in the Pending Changes list.
So just run your tool locally to go and bulk change all the html files. Then fire up VS and look in the Pending Changes window, all changed files should be listed and can be checked in.
.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.