8

My (large) company uses Perforce for most of their source control. (I can't escape this.)

A coworker and I often have to work on the same XML-based file at the same time. When it comes time to merge our changes, P4Merge is often not as smart as I'd like. For example, consider this super-simple XML file and two colliding variations:

Simple XML file and two variations with the same closing tag in the same place.

As shown, P4Merge is not XML-aware, and keeps only one copy of the common </b>.

How do you either modify the Perforce tool itself to support smarter XML merges, or how could you modify the Perforce toolchain to use a smarter merge tool as part of the Resolve process?

Phrogz
  • 296,393
  • 112
  • 651
  • 745
  • I'm not even sure such a XML-aware merge tool exists. This seems like one of the reasons why merge conflicts require human input. (And why you should structure your code to make related changes close to one another.) – millimoose Oct 16 '12 at 22:24
  • @millimoose FWIW, [some solutions](http://stackoverflow.com/questions/2222548/3-way-xml-merge-algorithm) do appear to exist. And yes; the fact that the file format currently puts logically-separate changes next to each other in the XML is something I'm also pushing to address internally. – Phrogz Oct 16 '12 at 22:42

4 Answers4

5

There's a tool called Project:Merge that might do a better job of handling XML content, and it integrates with Perforce:

http://www.projectmerge.com/help/en/integratep4v.php

Update: Project:Merge has been renamed to Oso XML Merge and updated since this post was made. The most recent version can be found here.

Quill
  • 2,729
  • 1
  • 33
  • 44
randy-wandisco
  • 3,649
  • 16
  • 11
3

Assuming that you're using P4V / P4Win, you can change the default diff and merge tools from the Perforce tools to the ones that you prefer. See this page from the P4V manual.

gareth_bowles
  • 20,760
  • 5
  • 52
  • 82
1

Also you can upvote this as enhancement you'd like to see: http://p4ideax.com/ideas/585/intelligent-support-for-xml-when-doing-merges

Ondrej Svejdar
  • 21,349
  • 5
  • 54
  • 89
-1

Just to note what you're complaining about isn't unique to XML. This is true of any block of code that has a common end. Consider if you add an "If ... Then" block to a vb.net program and your coworker adds a totally different "If ... Then" block in the same spot of the code. P4Merge would recognize everything up to the "End If" as different, but treat the "End If" as common to both - same as the XML block end. P4Merge allows you to edit as necessary, so just accept the co-worker's code, edit in the needed </b>, save so P4Merge reloads the compare, and you will see the new P4Merge compare will see the co-worker's code as common and just show yours as different. If on the other hand you want to reject the co-workers update, you're still no worse off as your code would still need the </b> (which wouldn't be touched by P4Merge...). Or if you need to merge parts of his with parts of yours, well that's also an edit and you'll likely end up needing just the one </b>, which is pretty much what P4Merge is telling you should happen. P4Merge is ultimately correct re: how its handling this compare.

Tom Turkington
  • 19
  • 1