locked
TFS merge file with no change RRS feed

  • Question

  • Hi,

    I have tried to merge several files from Main to Developement branch. Among the result merged files in local, there's one file (ex. file1.cpp) which its content has no change compared to the latest version (prior to merge) in Development branch. However, TFS allows me to checkin the merge including the file file1.cpp. The file in question (file1.cpp) is shown in the new changeset with action "merge, edit". And its content is the same as the version prior to the merge.

    Is this a normal behavior of TFS merge operation? In general, TFS does not allow to checkin file without change in its content.

    Any clarification or explication on this behavior would be appreciated.

    Thank you in advanced,

    Luong

    Monday, April 22, 2013 7:53 PM

All replies

  • Hi Luong,

    Thanks for your post!

    As far as I know, if a particular file is different in the two branches,  the file will have the status "merge, edit" because it is both merged from the branch and changed content-wise. Since the file1.cpp is the same as the prior version, so it displayed that.

    For example, if you have a Main with 2 files, make a Development of that, make a change in one of the files only and then to a merge, the pending changes on the Main should look like this:

    FileA.cs > merge
    FileB.cs > merge, edit

    After you perform a merge and check in it, a Conflicts window appears if you have changed the files content. For more information about this, please refer to http://msdn.microsoft.com/en-us/library/vstudio/ms181432.aspx

    Hope it helps!

    Best Regards,

    http://msdn.microsoft.com/en-us/library/ms181428.aspx


    Cathy Kong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, April 23, 2013 8:07 AM
    Moderator
  • Hi Cathy,

    My question is more related to TFS "checkin" policy for file has no change in content.

    Should TFS block files in pendingchange to be check-in if those files have modification type "merge, edit" and their content have not been changed (comparing with the latest version in TFS)?

    TFS already blocks files with no change and have modification type "edit".

    Thanks,

    Luong

    Tuesday, April 23, 2013 4:30 PM
  • Hi Luong,

    Thanks for your post!

    If TFS does a merge, it bases the merge on prior merge history, not on the actual contents of the source and target files. Based on my understanding, if a file's pending change type is "merge, edit", it is edited somewhere. I recommend you can view the file1.cpp file's history, and see if there is any change to make its type change to "merge, edit".

    Hope it helps!

    Best Regards,


    Cathy Kong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, April 24, 2013 7:12 AM
    Moderator
  • Hi Cathy,

    I understand the modification type "merge, edit" meaning the file has been edited. It could be edited by merge tool or via conflit resolution. However, when you have the action "edit" associated with a file in pending change, does TFS expect a real change in the content of the file and validate this prior to check-in? Why does TFS allow a file with no change and associated action type "merge,edit" to be check-in but it blocks file with associated type "edit"?

    May be the meanning of the word edit in action type "merge, edit" is different from  those of "edit"?

    Thanks,

    Luong

    Wednesday, April 24, 2013 6:33 PM
  • Hi Luong,

    Thanks for your feedback!

    The type "edit" means you edit a file and you don't check it into the TFS. It is not related with merge.

    The type "merge, edit" means you edit a file in one branch and merged it to the target file, and you 

    don't check in the target file to the TFS yet.

    So, you can check in the files marked as "merge, edit" files after you perform a merge.

    If you have any concern with it, please feel free to let me know.

    Best Regards,


    Cathy Kong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Thursday, April 25, 2013 2:55 AM
    Moderator
  • You did not answer my question (as the title of subject has said) which concerns about TFS checkin files with no change in content.

    TFS blocks the checkin of files which the modifciation type is "edit" and the content has not been changed. And I think it is perfectly fine. But in the case where the modification type is "merge, edit", TFS allows to checkin files with no change. Is this normal behavior? Do you have any explication on this behavior?

    Luong

    Thursday, April 25, 2013 12:51 PM
  • Hi Luong,

    Thanks for your feedback!

     

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Thank you for your understanding and support.

    Best Regards,


    Cathy Kong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, April 26, 2013 2:55 AM
    Moderator
  • I'm pretty sure that we fixed this in TFS 2012. The check-in server logic is now quite clear: if the hash value on the new content matches the hash value on the old content, the edit bit gets stripped. And if there are no bits left, then the entire pending change goes away.

    But even if you're using an older version of the product, this isn't a very big problem. This is an example of a bug with almost no consequences. At worst, you might see a History view where you think the file was changed in a particular changeset, but when you go to diff it, you find out that it did not actually change.

    Thanks!
    P. Kelley
    Version Control


    Saturday, April 27, 2013 12:59 AM
  • P Kelly,

    Is it indeed a bug then? I had been under the impression that by default the /force flag is set to false, which takes care of NOT checking-in a file if there are no changes to it. This was introduced in TFS 2010 onwards and remains undocumented on MSDN for TFS 2010.

    If it is indeed a bug I can think of at least one scenario with consequences. We have cases where a hot fix needs to be released. This involves patching an environment with only the changes for a quick resolution. So, it could mean the release of only one sql file or only one dll/ exe to a web server or windows service. Each of these releases are implemented by different teams that have to be booked for service in advance. If a changeset is going to include files that MIGHT NOT have changed, it would be a waste of time, effort and resources when TFS shows or records false changes!

    But I have also had scenarios where I have got a message 'There are no pending changes' during check-in of files without changes in it. So, it leaves me confused now.

    If the understanding is correct, as a workaround, for TFS, I suppose the release manager and/ or the developer will have to maintain a separate release register to record the intended list of files. 

    Interesting discussion that one.

    Regards,
    Rahul

    Saturday, April 27, 2013 5:28 AM
  • The merge problem occurred on TFS 2010 server & TFS 2010 client. We have recently migrated to TFS client 2012 (VS2012) but our server is still running version TFS 2010

    This behavior generates excessive information and work (unnecessary merge later). And, it can mislead users on the true state of change in files. We caught a case where a file has been merged,edit with no change in content from a development branch to its main/integration branch. Later on, the file was forward merged from the main branch to all its children branches (in our case, the integration branch has >30 children branches).

    Attached is the view history of a file showing merges performed back and forth between the 2 branches V2013 & RV2013 without any change. What it worries us more is the file was merged to its child branch (RV2013) and TFS allows to merge it  back to its parent branch (V2013). All of the merge described below has no change in content (diff tool shows no difference). Any thought on this behavior?

    V2013 is the parent branch of RV2013 & LIN2013

       - C13522 (branch LIN2013) -> C13777 (branch V2013)

       - C13777 (branch V2013) -> C13874 (branch RV2013)

       - C13874 (branch RV2013) -> C14279 (branch V2013)

    According to you, this bug should be fixed in TFS2012. We are planning to upgrade our server to TFS 2012 in September. Meanwhile, would you have any suggestion how to prevent this type of merge (no content change) into our server?

    Thanks,

    Luong


    • Edited by Hangluong Monday, April 29, 2013 6:29 PM correction on typo made on TFS server
    Monday, April 29, 2013 1:33 PM
  • Cathy and P. Kelly,

    Would you have any update on this subject?

    Thanks,

    Luong

    Wednesday, May 1, 2013 2:43 PM