tags:

views:

232

answers:

3

Hi,

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

+1  A: 

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

Kaius
Creating an application named PowerToys for the bug fixes and missing features, M$ genius.
Serkan
+2  A: 

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?

Martin Woodward
The actual changeset indeed doesn't include the file. I was confused by the fact that the file was ticked in the 'pending changes' list.
jan
+1  A: 

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:

  • ASCII -> 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.

Richard Berg
I'd like to mark your answer as accepted too. See my comment on the answer. I understand that copy-paste can indeed introduce 'invisible' changes. Could you point me to info about the merge-exception? I didn't quite understand that. Thank you!
jan
Simple example: you merge BranchA -> BranchB, but while going thru the conflicts, you decide you want to keep BranchB\foo.cs the way it is. It will retain a pending change of "merge" (vs the more common "merge, edit") and become part of the changeset history. As a result, if you do another merge from A -> B, TFS knows to skip over BranchA\foo.cs (unless there have been subsequent changes to it). /// There are other cases where you'd see something similar, but the basic idea is the same.
Richard Berg