P4merge license Patch#

It's obvious that this approach can mess up the patches as much as a line-based merge tool. There are many things to discuss and to test. In rare cases choose the Base value (e.g. If a certain attribute got changed in both versions: Choose remote.Intuition for now: focus on the bold changes If some child elements or attributes got removed, then remove them (no matter if they got changed in the other version).If the other one also added new child elements: take them too! these should come with different GUIDs.If one element got new child elements or attributes: take them.So let's just work on an XElement and XAttribute level. In this first naive implementation, we try to come up with a solution that covers most cases. In this first sketch, we load the three VL documents just as an XElement structure. Let's access the different versions ( Base, Local, Remote) in the same way that p4merge and other merge tools do: via command-line arguments. Let's build a small application that gets called by git merge. Dev B added an implementation of the old interface as known from Base But ideas might still collide: Dev A changed an interface and all its implementations. different patches/canvases: Sounds easy to be merged.But it's not likely that the different ideas will merge semantically and the result will just run. same patch/canvas, different ends: This should be mergeable.Note: it would be so cool to solve that in the future

P4merge license Patch#

structural changes: This is unmergeable for now since the only way to do those structural changes (via patch editor) is to copy and paste the definitions resulting in new GUID-Ids for all the elements.

These changes sound like real bad conflicts, but then again: often your changes are not really about nodes that got moved.

But maybe we can come up with something that doesn't feel so harsh. Changes were made on different patches/canvases.Changes were made in the same patch or the same canvas.Dev A moved a bunch of definitions into a new Category or Group.The version of a dependency changed on Local and Remote.a node was moved on Local and on Remote.So relating documents in different versions should be mostly about relating elements with the same Id.

Merging patches shouldn't be harder, but easier to merge than textual code.ДЄ document is a tree of elements, where each element is identifiable via its Id (a GUID). This tool is the first step towards an easy-to-use visual merge tool. Merging VL documents with traditional tools is hard.