Baseless merge ?

I've been told a couple of times to workaround problems with branching via a Baseless Merge.  Now I'm pretty sure I can guess what this does based on the name, but I can't find any way to accomplish this through the VS2005 UI.

I've read all the docs I can find and I've searched google and all I've come up with is the command line option to do "h.exe merge /baseless" from MSDN and the reference from Buck's blog.

The description in the docs being :

/baseless - "Performs a merge in the absence of a basis version"

Am I missing something in the UI or is it just not in there yet


Answer this question

Baseless merge ?

  • sasi

    This is not available in the UI, no. We don't currently have plans to add this functionality.

  • Tampali

    Excellent. Thanks, Richard that worked a treat. I'm going to setup all our branch relationships this weekend.

    Although I did hit 5 occurrences of the previously mentioned automerge bug (I'm still waiting for my support incident to be answered to get the hotfix), but it was no problem sorting each of those files out manually.


  • Paolo Giorgio

    [UPDATE May 26, 2006]  Baseless merges establish merge history in RTM!  See http://blogs.msdn.com/buckh/archive/2006/02/06/525896.aspx for more details.

    That's pretty close.  After importing everything from VSS, you can delete the destination of the share (i.e., the place you shared into), check it in, and then branch the source of the share (i.e., the code that you want to share) to the destination and check it in.  Now, you merge changes whenever the code that you shared changes.

    I'm hoping that baseless merge will be changed back to recording merge history.  I'll be sure to mark it as a customer issue.


    Buck



  • stegus

    Aha.. Thanks Buck.  I'd completely misunderstood the point of a baseless merge.

    Am much happier now :)


  • mamma

    You can find more info about baseless merges in the following blog post.

    http://blogs.msdn.com/buckh/archive/2006/02/06/525896.aspx

    Buck



  • jgams

    Still looking into why we can't have a more helpful /discard function. Meantime, here's plan B:
    make a copy of the tgt tree
    merge /baseless src tgt /r
    resolve /auto:acceptmerge
    overwrite tgt with your backup copy
    checkin

  • ambi

    Merge, including /baseless merge, never looks at file contents. It would be a nice optimization if baseless merges avoided conflicts by comparing hashes, but that's not a feature we have right now.

    I think you're seeing the correct /discard behavior. It automatically treats everything as AcceptYours. As you've discovered, that means in subsequent merges, the base file will be the original base (for /baseless, that's the beginning of time) rather than the version you last merged from.

    I'm trying to think of a process that would give you a "better discard" (i.e. where the SourceLastMerged gets incremented yet the target contents aren't touched) but am stumped at the moment...stay tuned...

  • Jack T

    To migrate from VSS we just brought across flat copies of our trunk and branch folders without history. Unfortunatly we just created normal folders in TFS to house these branches instead of creating proper branches, so TFS doesn't know they are related. It's my understanding that this is pretty much what the VSS migration stuff does anyway

    Thanks for the link to the automerge hang, I've filed a support incident and am waiting for someone to get back to me.

    I suspect the automerge wouldn't solve my problem though, as I think it will try and merge changes from the branch to the trunk. I just want to establish a relationship between them as they stand now (both being a little different from each other). So that from this point on, I can do a simple merge to merge new changes from trunk to branch and vice versa

    I think if I manually resolve all 9000 or so changes I might get what I want, but I still don't understand why it's prompting me to resolve changes between identical files (see above). Discard I think is what I want, but again it doesn't work as I'd expect.

    Thanks in advance

     


  • Carlos Pieren

    First of all, the loss of /baseless history that happened in June '05 is no more: we went back to the old behavior.

    How did you create the branch you're referring to If you created it in TFS directly (not migrated from VSS) then there's no need for /baseless.

    There's a hotfix available for the automerge hang. See here.

  • Aleydis

    Hmm..  This leaves me a bit stuck.  The advice I've been given a couple of times now to deal with the fact that the VSSConverter doesn't handle Shared & Pinned folders is to use Baseless Merging...

    Does this mean I should ask my developers to use the command line interface for the next few years until the old shared folders become obselete and no longer needed for support & bugfix

    Link to last recommendation to use Baseless Merging :
    http://forums.microsoft.com/msdn/ShowPost.aspx PostID=12431


    Link to page explaining the approach we use for our versioned source control (see the section called "Eric's Preferred Branching Practice" :
    http://software.ericsink.com/scm/scm_branches.html

    I don't get the product strategy here   What am I missing

  • TenDot

    If possible can someone elaborate a little on this, or perhaps go into a bit more technical detail about what a baseless merge does.

    I've got a branch that's evolved a fair bit from the original trunk it came from. I'd like to establish a merge history between them. Meaning that I'd like to be able to do a recursive merge from the branch to the trunk, and only have differences flagged from this point, to allow development in a branch to be merged forward to a trunk.

    When I do a standard recursive baseless merge, all the files are flagged as version conflicts (around 9000 of them). The majority of the files when I resolve the conflict are identical and I need to pick either to copy from source or keep target version. If they are identical then what's the difference in the options I'm being presented

    So far I've not gone through all 9000 files. I've tried to automerge, but due to TFS bug #71990, automerge hangs on a bunch of the files.

    I've tried the discard option at the command line, thinking that's what I want. It almost does what I want. After using it, if I do a normal recursive merge between the branch and trunk it only flags the files I've changed after that point. However it does an automerge on the changed file (I can't seem to stop it), and it thinks that everything that's different in the source file should be in the target, not just my recent changes. Which is what I thought the creation of a merge history was meant to prevent


  • jbtechie

    Not all of the command-line options are available via the GUI (at least in Beta 2). I think this is one of them.
  • shaikat

    The VSSConverter doesn't convert shared folders as branches.  Thus, there's no way to merge changes between what the "source" of the converted VSS share and the "target" of the share.  The source and the target have no branch or merge history that connects them.

    This is where the baseless merge comes in.  The purpose of the baseless merge is to establish a merge history between the source and destination.  A baseless merge creates merge history where there was none before.  In a normal dev scenario where you aren't converting from VSS, branching is what establishes the relationship to allow merging changes between the source and target.

    After the conversion is complete, perform a baseless merge between the source and the target of each converted VSS share.  Check in the baseless merge.  Now the source and the target are related through merge history.  As the source (or target) change, the changes can be propagated using the regular (not baseless) merge (either the command line or the GUI merge wizard).

    So, you only need to do the baseless merge once per shared source and target pair to establish the merge history.


    Buck



  • Waif

    Re: 27th June update.

    Ah..  much less happy again now :(

    I think what you're saying if I can paraphrase, is that we'd need to :
     - migrate one branch across from VSS.
     - 'branch' it in VSTF to make a new branch of the right name.
     - nuke the contents of this new branch.
     - add the files from VSS from the original version of this named branch.
     - check in.

    Given the thousands of folders and tens of thousands of files, this scares me a lot and strikes me as a potentially error-prone manual process that'll get our source trees into a untrustworthy state :(

    If there's anything I can do to encourage the priority of this change to be increased, count me in for it!

    I'm starting to really hate the word branch incidentally.  Causes nothing but confusion with the changes from VSS when you're trying to explain things..

    Martin

  • Baseless merge ?