none
Need a way to forcefully remove changeset from merge candidate list

    Question

  • When I try to discard a changeset from the merge candidate list (for merges
    from my MAIN branch to my PRODUCTION branch), I get the error shown below:

    > tf merge /discard /version:765~765 /recursive $/xyz.Portal/MAIN $/xyz.Portal/PRODUCTION
    There are no changes to merge.

    The changeset remains on the merge candidate list.

    I have read some others posts on this forum where users have encountered the same
    error, and the advice given has been to go ahead and try to merge the changeset and
    deal with whatever fallout there may be.  In my case this produces an error
    message:

    TF14087: Cannot undelete '$/xyz.Portal/PRODUCTION/Web/Modules/Desktop/BRServices/AddContact.aspx.cs' because not all of the deletion is being undeleted.

    Even if I could get past this error, I really do not want to go this route.
    I do not want to merge this changeset.  Trust me, I have good reasons, but if
    you need to be convinced, here is why:  The folder which contained the 30 or so
    source files affected by this changeset was deleted from both the source and
    target branches (and the DEV branch) over a year ago, and I definitely do not
    want to try to re-create that folder on either branch.  Actually, it already
    has been re-created, but it's different now ...

    All I want to do is discard the changeset from the merge candidate list.  There
    has to be a way to force TFS to do this.  If there is no way to do it from the
    command line (using one of the tf commands), then there must be some SQL
    command(s) I can run directly on the SQL Server database which supports this
    TFS project.

    Can someone tell me how to forcefully discard a changeset from a merge
    candidate list?

    BTW, I'm running Visual Studio Team System 2008 (SP1).

    mkedwards

    Wednesday, March 25, 2009 8:10 PM

Answers

  • mkedwards said:

    P.Kelley,

    I tried using the /force option together with the /discard option and got the following error message:

    Option /force cannot be combined with option /discard.

    So, unfortunately, that doesn't work.


    mkedwards


    That's right, you can't combine /force with /discard, however, you can combine /baseless with /discard. Baseless merge implies force, because it ignores merge history. But first, you need to get this fix: http://support.microsoft.com/kb/959168

    • Marked as answer by mkedwards Thursday, March 26, 2009 6:14 PM
    Thursday, March 26, 2009 4:25 PM

All replies

  • What happens if you add the /force option?

    tf merge /discard /force /version:765~765 /recursive $/xyz.Portal/MAIN $/xyz.Portal/PRODUCTION

    Do you get the same "no changes to merge" ?
    What are the changes in changeset 765?
    Wednesday, March 25, 2009 9:10 PM
  • If you can also provide the output of tf merges /r $/xyz.Portal/MAIN $/xyz.Portal/PRODUCTION and tf merge /candidate /r $/xyz.Portal/MAIN $/xyz.Portal/PRODUCTION, that will be helpful.
    Wednesday, March 25, 2009 9:23 PM
  • P.Kelley,

    I tried using the /force option together with the /discard option and got the following error message:

    Option /force cannot be combined with option /discard.

    So, unfortunately, that doesn't work.


    mkedwards

    Thursday, March 26, 2009 1:16 PM
  • Mohamed,

    Could you please look up my e-mail address and send me an  e-mail address (of yours) to which I 
    can send detailed output to?   I'd rather not post detailed information containing user logins and
    other information to this forum.

    If necessary, we can always open up a support ticket instead of going through the forums.

    I'd would like to add that the changeset that is causing the problems has over 50 files scattered
    over multiple folders (including App_WebReferences and App_Code folders).  In the meantime,
    (it's been a year since the problem occurred), we have clobbered the folders in all 3 branches,
    created new changesets, and successfully merged all of these files and folders to the target branch. 
    So this is why I do not wish to merge this old changeset.  I just want to discard it from the merge
    candidate list.

    mkedwards
    Thursday, March 26, 2009 1:26 PM
  • mkedwards said:

    P.Kelley,

    I tried using the /force option together with the /discard option and got the following error message:

    Option /force cannot be combined with option /discard.

    So, unfortunately, that doesn't work.


    mkedwards


    That's right, you can't combine /force with /discard, however, you can combine /baseless with /discard. Baseless merge implies force, because it ignores merge history. But first, you need to get this fix: http://support.microsoft.com/kb/959168

    • Marked as answer by mkedwards Thursday, March 26, 2009 6:14 PM
    Thursday, March 26, 2009 4:25 PM
  • Ok, this weekend, I will upgrade our TFS server to service pack 1 (we have upgraded our Visual Studio Team System
    clients to SP1 but have not yet upgraded the server) and apply the hotfix.  I will then try using
    both the /baseless and /discard options to the "tfs merge" command.

    Hopefully that will do the trick.    I'll go ahead and mark your response as the answer.

    Thanks for your help, Mohamed.

    mkedwards
    Thursday, March 26, 2009 6:14 PM
  • mkedwards, I hope this works for you. Please let us know if you have any questions.
    • Proposed as answer by ce_wilson Tuesday, November 24, 2009 11:50 PM
    Thursday, March 26, 2009 7:05 PM
  • Just for informational purposes you might want to put a "C" in front of changesets, this command about crashed our production team server without it.

    Example: tf merge /discard /version:C765~C765 /recursive $/xyz.Portal/MAIN $/xyz.Portal/PRODUCTION

    yea i need a beer
    Tuesday, November 24, 2009 11:50 PM
  • "C" doesn't do anything.  You can use SQL Profiler to verify they generate the exact same command.  If you found the command was doing far more work than it should have, chances are you only gave one version (leaving the range half-open).
    Wednesday, November 25, 2009 4:24 AM

  • Wow, surprising that comments are being posted to this thread so many months later.    For what it's worth, I did try combining the /baseless and /discard options when issuing the tf merge command and had success with this on almost all of the changeSets that I was trying to discard, but there were 1 or 2 that I couldn't discard no matter what I tried.   So they will remain on the merge candidate list for all eternity I guess.

    I don't know if anyone from Microsoft is reading this, but if so:  it would be nice if discarding merge candidates did not create a pending changeset (essentially a null changeset) that has to be checked into the target branch.  In my opinion, this is clutter that I really don't want to see, i.e. I don't want to see any changeset (relating to the source changeset) on the target branch when I do a discard.   I sincerely hope this will be changed in a future version of Team System.

    Mike
    Wednesday, November 25, 2009 3:10 PM
  • Interesting idea, Mike.  Introducing the concept of a "null" changeset would require big changes throughout the backend.  But let's focus on UI: what should merge history look like in your mind?  Today's tf merges shows:

    Changeset Merged in Changeset Author                           Date
    --------- ------------------- -------------------------------- ----------
       12502                12694 rberg                            11/13/2009
       10773                11056 rberg                            7/27/2009
       11722                11961 rberg                            9/18/2009
       11726                11961 rberg                            9/18/2009
    Discarded changesets have to appear in the list somewhere (to distinguish them from changesets that are still candidates).  Presumably we'd still want to record when the discard happened, who was responsible, and an optional comment why they are discarding.  We'd need to store the list of files too or we'd lose a fair bit of existing functionality (detailed merge history, used by everything from TFS 2010's pretty visualizations to the migration toolkit; partial discards; normal merges where the user resolves a conflict as "keep target branch").  Add it all up and you're essentially describing a changeset.  No escaping that, I don't think.  

    Only remaining question is what we want to appear in the 2nd column.  A number + some kind of marker?  (like today's asterisk for partial merges)  Something else entirely?  Chances are TFS could improve this experience significantly without altering any core concepts.

    As for excluding it from regular history on the target, I'm less convinced.  For casual scrolling thru the history, informative changeset comments will always provide more relevant info than anything the system can generate.  For automated scenarios, it's trivial for programs/scripts to detect changesets that contain only Merge changetypes should that become necessary.
    Wednesday, November 25, 2009 6:58 PM

  • Richard,

    Thanks for your response.  I wasn't proposing introducing a null changeset.  I was describing the current behavior when I used the phrase "null changeset".  Currently, when you discard a merge candidate, a null changeset is generated and has to be checked in on the target branch.  

    When I discard a merge candidate, I don't want any new changeset to be placed on the target branch (or at the very least, if needed for low-level implentation reasons, that should be completely hidden from me).  I'm all for maintaining a detailed history with all the information describing when (and by whom) the source changeset was discarded as a merge candidate .... that makes perfect sense.  But why in the world would I want anything new to appear on the target branch?   That just doesn't make sense.  It's clutter.

    As for the UI, I'm sure some way of presenting the information (in a clear way) about a discarded merge candidate can be dreamed up. 

    Mike

    Wednesday, November 25, 2009 7:16 PM
  • If you can also provide the output of tf merges /r $/xyz.Portal/MAIN $/xyz.Portal/PRODUCTION and tf merge /candidate /r $/xyz.Portal/MAIN $/xyz.Portal/PRODUCTION, that will be helpful.

    Thanks to the reminding!
    Friday, February 18, 2011 2:24 AM
  • Interesting idea, Mike.  Introducing the concept of a "null" changeset would require big changes throughout the backend.  But let's focus on UI: what should merge history look like in your mind?  Today's tf merges shows:

    Changeset Merged in Changeset Author                           Date
    --------- ------------------- -------------------------------- ----------
       12502                12694 rberg                            11/13/2009
       10773                11056 rberg                            7/27/2009
       11722                11961 rberg                            9/18/2009
       11726                11961 rberg                            9/18/2009
    
    Discarded changesets have to appear in the list somewhere (to distinguish them from changesets that are still candidates).  Presumably we'd still want to record when the discard happened, who was responsible, and an optional comment why they are discarding.  We'd need to store the list of files too or we'd lose a fair bit of existing functionality (detailed merge history, used by everything from TFS 2010's pretty visualizations to the migration toolkit; partial discards; normal merges where the user resolves a conflict as "keep target branch").  Add it all up and you're essentially describing a changeset.  No escaping that, I don't think.  

    Only remaining question is what we want to appear in the 2nd column.  A number + some kind of marker?  (like today's asterisk for partial merges)  Something else entirely?  Chances are TFS could improve this experience significantly without altering any core concepts.

    As for excluding it from regular history on the target, I'm less convinced.  For casual scrolling thru the history, informative changeset comments will always provide more relevant info than anything the system can generate.  For automated scenarios, it's trivial for programs/scripts to detect changesets that contain only Merge changetypes should that become necessary.

    For what it's worth, all these many years later, it would be great if something like "merge, discard" was a first-class change type in TFS. I feel like this makes big strides for preservation of intent, specifically for the future-user who might stumble upon a mysterious changeset from years before that for some reason had only "merge" change types. In my experience, users are utterly terrified of merge changes with no edits.

    Thursday, January 03, 2013 10:11 PM