I suppose you could put it that way in a vague sense, but it’s not really what I was referring to with that comment. What I was talking about is that if you have two different XML files with divergent structure, to ensure that those files are merged correctly you would need to have some understanding of how they are meant to look in a coherent state once merged. That would require not only knowledge of how XML should be formed in broad theory, but how Scrivener employs that technology, what internal schema it uses and as well as how the data it requires is structured within that schema.
It’s a similar problem with RTF, which is also a plain-text format, but unlike XML, non-structural and much more opaque in terms of human interface. Consider if both parties modified the same binder item to use different styles. You would need to be able to correctly merge Scrivener’s .styles file in the respective resource folder where the RTF is found and ensure that the RTF headers are properly sequenced to reference those styles, and that all internal RTF references, on a paragraph and inline scale, are pointing to the correctly merged sequence.
It would probably take a skilled RTF “hacker” a lot of work to do that, and you’d have to do it for every file that was forked. I think at this point it’s good to consider the scale of a Scrivener project. A mature and large project may be comprised of many hundreds if not thousands of such files, any number of which might be in need of repair on an individual hand-coded basis, depending upon how divergent the fork is—and that’s just a two-way fork. I’d throw my hands up in despair at the thought of having to merge four or five divergent RTF files coherently, let alone hundreds of them.
The merging system that I referred to in my last post will allow for some rudimentary collaboration. This system is definitely capable of distributing satellite copies of a project to a number of people, and merging them back into a master project by the coordinator.
It will not resolve individual item conflicts however. That’s way too complicated and subjective to do correctly with an algorithm. It will however enumerate those conflicts so they can be resolved by a human using the natural project user interface. If you’ve ever used the iOS version then you may know what that is like. If you accidentally edit the same binder item in two places without syncing, then you end up with a duplicate copy in the binder so that you can yourself merge the text appropriately.
And to reiterate in case it is not clear: this is definitely a case of distributing copies of a project which are edited independently. This technology will not work on some central repository upon which people pull and commit. It is designed to take Project A and import it into project B, and detect that A came from B at some point and offer to merge in the modifications to B (rather than import the entire binder separately). If there is no A or B, as would be the case with a single repository, then this feature does not exist.
As for roadmaps, go ahead download the Mac user manual from the website, and flip to §5.3.2, Merging Projects, pg. 74. That will cover how this feature works and what to expect from it. It’s designed to be easy to use, not complicated like a git repository. Ease of use comes with the compromise not being as powerful as CVS, but it means one doesn’t need a background in IT to collaborate with another author.