This is one of the key problems about lively.next that make it unusable for teams working on the same project.
Once conflicts arise between two version of the same world, there currently is no assisted way of reconciling these two conflicting versions. Instead the users have to merge the different worlds "by hand" which usually means copy and pasting code and morphs between the worlds until one is reasonably sure nothing was missed. This is not acceptable, especially for professional usage scenarios.
Below I outline the problem in detail and suggest a first approach that could provide a reasonable first attempt at solving this issue.
What is the problem with merging worlds?
To my knowledge, state of the art collaboration between programmers happens on the basis of documents, that can mostly be compared via text diffing. For more complex structured data, it is fairly easy to create custom views that allow to create more meaningful diffs between conflicting documents.
This then allows the programmer to make reasonable decisions about how a reconciled version of two conflicting versions of a document should look like. It is important to keep in mind that this still requires a good understanding of the code/document itself, since accidental merge errors still appear all the time. So saying that this is solved to perfection and everything is hunky dory is not what we are talking about. This more somewhat the baseline of what we have to measure merging worlds with.
So what is the problem with worlds then? Regarding the code that is stored inside worlds, there is the good news: no problem at all. We can compare source files just the way "state of the art" reconciliation happens. But what about the rest? Well the "state" of worlds (meaning the collection of morphs and other objects in the worlds) are not documents but graphs. And even worse, they are basically cyclical graphs in almost all cases. Comparing two cyclical, directed graphs is a problem that has not yet been solved yet (again correct me if I am wrong).
So what do we do? Well many have tried and here are some pointers:
The wonderful @athomschke has written a lot about versioning parts in lively and merging/reconciling conflicting changes. @JensLincke Maybe you can link her thesis somewhere here, I could not find it. If I remember correctly, her approach was based by reducing the diffing to just source code changes and a particular "reserved set of props" which usually means something like the set of all morphic props. However this of course eventually ignores some part of the remaining i.e. custom state that then can just be decided between but not merged in a meaningful way anymore.
Another idea is to ditch asynchronous collaboration all together and turn lively into a real time collaboration system, similar to google docs. One direction we could go is to finally fix the unde/redo mechanism in lively and hook it up with the technology from the guys at croquet.io. However this opens up a whole other can of worms which I do not have time to go into here. (Preview: When propagating changes to other clients what happens with operations based on machine specific results, i.e Date.now() or Math.random()... etc)
Anyone feel free to add more perspectives on this. But I think this basically illustrates the problem.
Next steps
I will read up on the thesis of @athomschke and then complete this ticket with a first concrete approach we can talk towards a "world differ"
This is one of the key problems about lively.next that make it unusable for teams working on the same project.
Once conflicts arise between two version of the same world, there currently is no assisted way of reconciling these two conflicting versions. Instead the users have to merge the different worlds "by hand" which usually means copy and pasting code and morphs between the worlds until one is reasonably sure nothing was missed. This is not acceptable, especially for professional usage scenarios.
Below I outline the problem in detail and suggest a first approach that could provide a reasonable first attempt at solving this issue.
What is the problem with merging worlds?
To my knowledge, state of the art collaboration between programmers happens on the basis of documents, that can mostly be compared via text diffing. For more complex structured data, it is fairly easy to create custom views that allow to create more meaningful diffs between conflicting documents.
This then allows the programmer to make reasonable decisions about how a reconciled version of two conflicting versions of a document should look like. It is important to keep in mind that this still requires a good understanding of the code/document itself, since accidental merge errors still appear all the time. So saying that this is solved to perfection and everything is hunky dory is not what we are talking about. This more somewhat the baseline of what we have to measure merging worlds with.
So what is the problem with worlds then? Regarding the code that is stored inside worlds, there is the good news: no problem at all. We can compare source files just the way "state of the art" reconciliation happens. But what about the rest? Well the "state" of worlds (meaning the collection of morphs and other objects in the worlds) are not documents but graphs. And even worse, they are basically cyclical graphs in almost all cases. Comparing two cyclical, directed graphs is a problem that has not yet been solved yet (again correct me if I am wrong).
So what do we do? Well many have tried and here are some pointers:
The wonderful @athomschke has written a lot about versioning parts in lively and merging/reconciling conflicting changes. @JensLincke Maybe you can link her thesis somewhere here, I could not find it. If I remember correctly, her approach was based by reducing the diffing to just source code changes and a particular "reserved set of props" which usually means something like the set of all morphic props. However this of course eventually ignores some part of the remaining i.e. custom state that then can just be decided between but not merged in a meaningful way anymore.
Another idea is to ditch asynchronous collaboration all together and turn lively into a real time collaboration system, similar to google docs. One direction we could go is to finally fix the unde/redo mechanism in lively and hook it up with the technology from the guys at croquet.io. However this opens up a whole other can of worms which I do not have time to go into here. (Preview: When propagating changes to other clients what happens with operations based on machine specific results, i.e Date.now() or Math.random()... etc)
Anyone feel free to add more perspectives on this. But I think this basically illustrates the problem.
Next steps
I will read up on the thesis of @athomschke and then complete this ticket with a first concrete approach we can talk towards a "world differ"