Text Merge vs. 3-way merge

[ron]

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.

[Michael Bulgrien]

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.

[Aaron]

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?

[Unregistered]

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.

[Tim]

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.

[Michael Bulgrien]

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?

[Michael Bulgrien]

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.

[Zoë]

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.

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?

[Michael Bulgrien]

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.

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.

[GreenMoose]

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.

[Erik]

FYI, if we just moved the output pane to the middle, lines would not necessarily line up - the output can have extra lines inserted throughout. Whenever a line is output only, all 3 input panes would have to have a gap. In order for the output pane to be movable, those gaps would have to always be there.

[Michael Bulgrien]

I would not expect the pane to be moveable without a redraw...in which case the gaps can be inserted as needed when the output pane is viewed in the center pane.

[Tim]

Could you update the roadmap, please?

The roadmap says 3-way folder merge is expected in 3.?, which means some version 3 release beyond 3.0. It's way too early to say what will be in 3.1. My current guess is that folder merge will make it into 3.1 but that's not solid enough for the roadmap.

Actually, I'll probably be dropping the features roadmap before the beta goes public. No matter how clear the disclaimer there will be people who consider these to be promises, and they are still quite tentative.

[Michael Bulgrien]

Thanks, Tim. I think I misread the roadmap the first time. I went back a few minutes later and noticed that it said 3.?

I wasn't sure if I misread it the first time...or if you were just super fast in updating it.

[Erik]

gaps can be inserted as needed

We can't do that - it breaks the rules of undoability. Also, we filter the input but not the output. In short, it would require a significantly different design to support this.