Page 1 of 3 123 LastLast
Results 1 to 10 of 21
  1. #1
    Join Date
    Dec 2007
    Posts
    123

    Default Text Merge vs. 3-way merge

    If I've missed a thread or blog on this, please point me to it.

    The help file currently uses the term Text Merge to describe what I think is a 3-way merge. Perhaps they are one in the same except that sometimes there's a center pane.

    A 3-way merge can only be invoked via the command line or supported CM Tool?

    The Compare In New View Using/Text Merge is something that I'll use more often now that I've found it. Kind of wish it were easier to get to but not sure that I want to have the option of making it the default when I hit enter from a folder view. Take Left then Right is just what I've needed for years. As for Take Center, what does that mean in the Text Merge context? Since there is no center pane, it seems to just wipe out the selection.

    Once I take what I want from the left and right into the Output pane, I wish it were easier to save that edit into either the left or right file, replacing it. In my case the right file is usually the one checked out that others have been working on since my last snapshot. So I need to merge those changes with mine into a third file that I'll turn around and check in.

  2. #2
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default 3-way Compare?

    Yes, the text merge in Cirrus is a 3-way merge. Without the center pane, it becomes a 2-way merge. Perhaps this thread discussing a 3-way compare is what you're thinking of.
    Last edited by Michael Bulgrien; 10-Jan-2008 at 10:06 AM.

  3. #3
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,782

    Default Center Pane

    The center pane is not immediately viewable, but if you will notice there are three address/location bars at the top of the window. 2 for each visible pane, and a middle third one. If you drag a file on top of the third bar, it will open the middle pane.

    One traditional use of the Merge tool is to have a common ancestor. In your example, you have Your file, and Their file. You are taking your changes in Your file and putting them into Their file, making sure it works, and then checking it in.

    If you have a common Ancestor then you will find your Merging will go a bit smoother. An ancestor would be the initial version of the file before you made any changes to it, and would have been the most up to date with Source Control before making those changes. This way, the Ancestor is the file before you, or anyone else, have altered it. The Theirs pane then reflects what the other programmers have done since you obtained the Ancestor, and the Yours pane would reflect what you have done since you obtained the Ancestor. The program will be able to suggest/see changes that you deleted/added, and not every change will be a conflict; only changes that were altered by both parties (Yours and Theirs).
    This is all commonly handled by Source Control software (such as SVN). You just need to setup the Source Control software's parameters correctly when calling Beyond Compare.

    Is there a workflow reason you want to save over Their file, rather than create a new one? If you didn't mind overwriting Their file, why not use a 2 pane Text Compare, rather than Merge?

    Merge's advantage is it allows you to piece together your output pane, and then save that wherever, without altering the 2-3 panes used to construct it. Currently, you can manually select to save the Output pane over one of the other files, and it will not refresh that file in the upper pane unless you Refresh manually. You can configure the command line call to manage this for you.

    Could you go into more detail (step by step) of what you would like to do with Beyond Compare? Are you calling from Source Control Software?
    Last edited by Aaron; 10-Jan-2008 at 01:31 PM. Reason: more clear definition of Ancestor, expanded currently available options section
    Aaron P Scooter Software

  4. #4
    Unregistered Guest

    Default

    Very likely the text merge is enough especially for merging difference in revison control system.

    What is the plan to support 3-way diff of folders? Even though it is rarely used, but it is definetely a must have feature when unfortunately needed 3-way differing.

  5. #5
    Join Date
    Oct 2007
    Posts
    786

    Default

    3-way folder merge is about 75% complete, but we've shelved it for now due to time constraints. My current guess is that it will be in 3.1.
    Tim T Scooter Software

  6. #6
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    Quote Originally Posted by Tim View Post
    3-way folder merge is about 75% complete, but we've shelved it for now due to time constraints. My current guess is that it will be in 3.1.
    Could you update the roadmap, please?

    Also, I take it the current flattened folder feature is the "n-way folder compares" listed in the roadmap?

    What I did not realize about the flattened folders is that when I copy something from one side to the other, it does not copy into the same folder structure on the other side even if the same folder structure exists. With flattened folders, all files are copied to the base folder on the other side. Is this the intended behavior?

  7. #7
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    It is easier to compare panes that are side by side. Instead of having a separate output pane, one merge engine I tested allows you to swap between viewing the common ancestor and the merged output in the center pane. Although I don't have a problem with the current implementation, it would be nice if a future version of BC provided that flexibility to users that prefer not to have the forth pane.

  8. #8
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    2,518

    Default

    Quote Originally Posted by Michael Bulgrien View Post
    Also, I take it the current flattened folder feature is the "n-way folder compares" listed in the roadmap?
    No, n-way folder compares would have (will) extended the current 2-way folder comparison to include to a larger number of sides. Think a single source directory and a bunch of target directories.

    Quote Originally Posted by Michael Bulgrien View Post
    What I did not realize about the flattened folders is that when I copy something from one side to the other, it does not copy into the same folder structure on the other side even if the same folder structure exists. With flattened folders, all files are copied to the base folder on the other side. Is this the intended behavior?
    Yes, it's intended, though it could be changed based on feedback.

    If a file is lined up with something it will overwrite it; if it isn't it always goes in the base folder. Copying unaligned files is a bit up in the air; we could copy the folder structure if it already exists, but I think we'd have to keep the current behavior if the target directory didn't exists, which would make things a bit inconsistent. Plus, if the folder structures are the same on both sides, why are you using the flattened view?
    ZoŽ P Scooter Software

  9. #9
    Join Date
    Oct 2007
    Location
    Pennsylvania
    Posts
    1,772

    Default

    Quote Originally Posted by Craig View Post
    No, n-way folder compares would have (will) extended the current 2-way folder comparison to include to a larger number of sides. Think a single source directory and a bunch of target directories.
    Thanks! I just got confused since n-way folder compares and flattened folders were on the same line in the roadmap. My bad.

    Quote Originally Posted by Craig View Post
    Yes, it's intended, though it could be changed based on feedback. If a file is lined up with something it will overwrite it; if it isn't it always goes in the base folder. Copying unaligned files is a bit up in the air; we could copy the folder structure if it already exists, but I think we'd have to keep the current behavior if the target directory didn't exists, which would make things a bit inconsistent. Plus, if the folder structures are the same on both sides, why are you using the flattened view?
    I thought that flattened folders might make it easier to compare/sync deep folder tries that, when fully expanded, cause you to have to scroll left or right to view their contents. I tried it, but all my orphans on the left side ended up in the base folder on the right.

    I can see the advantages of copying to the base folder. I don't think that orphans with matching folders should be copied into their matching folders if orphans without matching folders are copied into the base folder. That would indeed be an inconsistency. I can see the advantages of being able to copy all files to a base folder on the other side. I am just wondering how many people will try something like I did.

  10. #10
    GreenMoose Guest

    Default

    Quote Originally Posted by Michael Bulgrien View Post
    It is easier to compare panes that are side by side. Instead of having a separate output pane, one merge engine I tested allows you to swap between viewing the common ancestor and the merged output in the center pane. Although I don't have a problem with the current implementation, it would be nice if a future version of BC provided that flexibility to users that prefer not to have the forth pane.
    I second this. When I've finished merging/editing the merge output, it would be nice to be able to compare the merged result to left/right side-by-side so I more easily can validate the final merge result before accepting changes.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •