Comments on: Collaboration and Merging True, there are other bad things that can happen. I'm not sure I'd call them "conflicts" though. In a way, they are more similar to the case in traditional merging when the merge is successful but you still get a compile or runtime error because of violated syntax/semantics. But they are "merge problems" for sure. The first case you mention, I think is easy. The result of merging a removal and a property change on the same object is that the object is removed. I.e., it doesn't matter if the property change happens before or after the removal, the end result is the same -- no object. In the second case the referential integrity of the data is broken, so the tools must be equipped to handle that. I.e., they must be able to treat a reference to a non-existing object in the same way as a null reference and handle that gracefully. And it is true that if there are other semantic constraints on the data than "referential integrity", they too can be broken by the merge, since it is not semantically aware. To take a silly example, if there is a constraint such as "the hit points of all enemies in the level must sum to 1000" that could easily be broken by the merge. The only way around that is to have the merge tool understand all the semantics, which is usually not practical. You can see "objects-with-properties" as a baseline semantic model. It is not as good as a completely custom model that understands what the data "means". But it is better than JSON or XML -- it represents meaning/intent/semantics better, while still being a general format. And for many of the assets managed in games I think the model is able to represent the semantics well enough to be used as the basis for merging and thus allow collaborative workflows. (There are of course lots of exceptions where the model doesn't work: source code, script code, raw sound data, textures, etc.) True, there are other bad things that can happen. I’m not sure I’d call them “conflicts” though. In a way, they are more similar to the case in traditional merging when the merge is successful but you still get a compile or runtime error because of violated syntax/semantics. But they are “merge problems” for sure.

The first case you mention, I think is easy. The result of merging a removal and a property change on the same object is that the object is removed. I.e., it doesn’t matter if the property change happens before or after the removal, the end result is the same — no object.

In the second case the referential integrity of the data is broken, so the tools must be equipped to handle that. I.e., they must be able to treat a reference to a non-existing object in the same way as a null reference and handle that gracefully.

And it is true that if there are other semantic constraints on the data than “referential integrity”, they too can be broken by the merge, since it is not semantically aware. To take a silly example, if there is a constraint such as “the hit points of all enemies in the level must sum to 1000″ that could easily be broken by the merge. The only way around that is to have the merge tool understand all the semantics, which is usually not practical.

You can see “objects-with-properties” as a baseline semantic model. It is not as good as a completely custom model that understands what the data “means”. But it is better than JSON or XML — it represents meaning/intent/semantics better, while still being a general format. And for many of the assets managed in games I think the model is able to represent the semantics well enough to be used as the basis for merging and thus allow collaborative workflows.

(There are of course lots of exceptions where the model doesn’t work: source code, script code, raw sound data, textures, etc.)

]]>
By: Stefan Boberg/2011/03/27/collaboration-and-merging/#comment-2050 Stefan Boberg Mon, 28 Mar 2011 08:18:43 +0000 Yes, it is a transaction log, but the point is not so much the log format itself but the objects-with properties model behind it which ensures that the data always can be merged with only one possible type of conflict: when two users have changed the same property of the same object. You don't have to represent the data as transaction logs for this to work. You could just as well use a JSON file (for instance). In that case, the diff produced by the "objects-with-properties"-aware diff/merge tool would be a transaction log similar to the one shown in the article, which you could then apply to another JSON file to merge in the changes. When it comes to conflicts (remember the only possible conflict is when two users have changed the same property of the same object) there are three main options (1) show the conflict in the content tool somehow and let the user resolve it there, (2) automatically let the newest property change override the oldest (or use some other heuristic to pick one) or (3) force the user to manually resolve the conflict by hand editing the data files. Arguably, (1) is the best option, but (2) is a lot better than (3). Your last comment about sorting the file assumes that you are still doing text-based, line-oriented diffs and merges. The whole point of this post is to get away from that. Yes, it is a transaction log, but the point is not so much the log format itself but the objects-with properties model behind it which ensures that the data always can be merged with only one possible type of conflict: when two users have changed the same property of the same object.

You don’t have to represent the data as transaction logs for this to work. You could just as well use a JSON file (for instance). In that case, the diff produced by the “objects-with-properties”-aware diff/merge tool would be a transaction log similar to the one shown in the article, which you could then apply to another JSON file to merge in the changes.

When it comes to conflicts (remember the only possible conflict is when two users have changed the same property of the same object) there are three main options (1) show the conflict in the content tool somehow and let the user resolve it there, (2) automatically let the newest property change override the oldest (or use some other heuristic to pick one) or (3) force the user to manually resolve the conflict by hand editing the data files. Arguably, (1) is the best option, but (2) is a lot better than (3).

Your last comment about sorting the file assumes that you are still doing text-based, line-oriented diffs and merges. The whole point of this post is to get away from that.

]]>
By: Stefan Boberg/2011/03/27/collaboration-and-merging/#comment-2048 Stefan Boberg Mon, 28 Mar 2011 07:05:55 +0000 I find this approach very appealing. We have cases where array order can be important, e.g. a list of actions to execute or conditionals to evaluate. However, it quickly became clear to me that 'array order' can be based on an array index property, effectively a priority, which allows us to merge move operations as easily as other property changes. I find this approach very appealing. We have cases where array order can be important, e.g. a list of actions to execute or conditionals to evaluate. However, it quickly became clear to me that ‘array order’ can be based on an array index property, effectively a priority, which allows us to merge move operations as easily as other property changes.

]]>