My programming environment / language (gamemaker) gives the source files as "XML-files". Each resource has its own XML file. Where the properties (code is a property) are stored inside xml tags.

Is there a source control which can handle these? With subversion collisions don't seem to be handled correctly: when a collision happens, subversion breaks the XML structure. Which in turn breaks Gamemaker when updating.

EDIT (editing here as comments don't seem to handle newlines :P), an example of a source file that got "destroyed" by subversion:

<<<<<<< .mine
>>>>>>> .r16

EDIT2: because of lack of experience with these tools, I asked the wrong question. So here a better wording:

In the example above an xml-file-reader will crash when trying to read the file. However manually resolving the conflict is "hard". (And in extreme cases impossible). "" doesn't say anything in itself. - As the first question becomes "parent name of what?"- An object? - which object? In this case one can see it quickly. However if the xml file reaches 100+ lines with 6-7 layers of tags it becomes a mess just looking through it. Especially as many tags are not named the same as they are in the IDE.

What I hoped to have is that the conflict to be changed in such a way an xml-reading library can read it. - For example that the .r16 change is displayed into a comment (or subtag/attribute).

<!--.r16: objExplosion--></parentName>

From that point on I can program a tool to help analyzing the conflict. - I can use one of the many xml libraries to write a simple application visualizing the tree.

Well I'm just surprised this hasn't been a problem to anyone else :/.

  • 3
    I would have thought most version control systems should be able to handle XML files without a problem. They're just text files to the system after all. Can you show what changes are breaking the structure?
    – ChrisF
    Dec 23, 2011 at 10:20
  • look under file conflicts tortoisesvn.net/docs/nightly/TortoiseSVN_en/…
    – paul23
    Dec 23, 2011 at 10:24
  • @ChrisF: Well I'm hoping "unresolved conflicts" still keep the xml-structure of the file. So that when analyzing the xml-file with an xml reader it doesn't crash. - Or is there an existing xml-reader that ignores/marks those things made by svn?
    – paul23
    Dec 23, 2011 at 10:30
  • You're talking about this GameMaker, right?: yoyogames.com/gamemaker/windows I thought everything was in one large binary file.
    – Agent_9191
    Dec 23, 2011 at 14:02
  • @Agent_9191 Not in HTML5/studio/all future versions.
    – paul23
    Dec 23, 2011 at 14:30

5 Answers 5


It looks like you you saying that a file with unresolved conflicts breaks Gamemaker.

Well, I'd expect that regardless the file type or system. You need to resolve all the conflicts before building. There's no way that having a file marked with unresolved conflicts can keep the structure of that file valid.

If this was a C# or Java source file I'd expect to get compiler errors if I tried to build the project with the file in this state.

  • 1
    Well maybe I wording it wrong: I was hoping for a manner to resolve conflicts by using an xml-editor/xml-reading library. As an option has makes only sense when looking at the whole tree, not as line/group of lines. So before one can resolve a conflict, one has to analyze in which part of the tree the conflict occurs.
    – paul23
    Dec 23, 2011 at 10:33
  • 2
    +1 for "regardless the file type or system". Conflicts need to be resolved. Always.
    – Oded
    Dec 23, 2011 at 10:34
  • @paul23 - I'm thinking that you might asked the wrong question. However, conflict resolution can only ever be local. It's the human that supplies the context.
    – ChrisF
    Dec 23, 2011 at 10:40
  • @paul23, there's no easy way out of this. You must get used to the "conflict sintax" of your source control system. On SVN pretty much you can resolve conflicts by accepting the incoming file, overwriting it with your own version of the file or manually merge it. You are having issues with the manual merge. Welcome to development on a team. This kind of thig will happen, so get used to it. No harm will be done to your skills.
    – Machado
    Dec 23, 2011 at 11:37
  • 1
    I'm guessing the problem may be that a borked file won't load in the development environment, so it's not possible to fix it (without firing up an external editor). So it's got a higher "hassle factor" than C# or Java, where you can simply bring up the file in the IDE, resolve the conflicts, and recompile.
    – TMN
    Dec 23, 2011 at 13:48

Git has the concept of custom merge drivers for just this purpose. It would allow you to merge xml files using your own algorithm instead of the default line-by-line. However, to my knowledge no one has written one for xml and made it publicly available. I don't know enough about subversion to know if it currently allows custom merge drivers, but since it is open source you can add it yourself. Either way, it seems like a lot of work on a tool unless xml merging is a major productivity drain.

  • 1
    Well I simply find it "weird" that for such a standard thing as XML files there is no diff/merge tool. (Which also support things such as whitespace, order of attributes & comments).
    – paul23
    Dec 23, 2011 at 19:54

SemanticDesign produce a line of language sensitive tools. Maybe you might be interested in checking those out.

Short of that, as 'Badger said, XML is a text file like any other, save of structure, and normal VCS's should work.


I don't think you find any VCS, which will work according to your needs currently (automagically).

Because all SCM (and diff-merge tools behind the scene) work with one string as minimal object of data, when you want to process *-entity (multi-sting) as integral object. You have to work with it by hand

EDIT for your EDIT2

I can't recall, how to resolve merge-conflicts easy in CLI SVN, but, if you can use any (good) GUI-capable differ-merger, which started on appearing of unclean merge, you'll have less troubles even with classic line-based merge: you see conflicts in context


I think that you just need a better merge tool. Dont ever save a file with those svn merge markers in them, resolve the conflicts first and only save valid XML documents.

We used to use XML files for configuration of our application and these were stored in the Mercurial repository along with the application source code.

Using kdiff3 with TortoiseHG I never had a problem that couldn't be fixed by looking at both branches of a merge and their common ancestor.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.