TFS commits unchanged files

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 j开发者_开发知识库ust 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.