It would be great the integration with control versions git. I think that it`s posible touse git for novels and similar, besides of programation code.
Besides, Bitbucket has private repository free and unlimited.
One integration in Scrivener gives very functionallity.
If you search the forum here for previous discussions on using git and other CVS with Scrivener, you’ll find the overall concensus is that while it works fine for very simple cases where there is one trunk that people pull from sequentially, it gets very messy very quick if you try to merge concurrent edits together. Basically you need the the one managing the merges to have a very deep understanding Scrivener’s XML formats, and probably how RTF works at a markup level, too, in order to pull off true merging. In general it is going to be easier to use Scrivener’s front-end tools for forking and merging projects (currently Mac-only, but coming with Windows 3; not sure if it’s in the beta yet), benefiting from its back-end conflict resolution logic in doing so; it uses the same core logic used to resolve syncs coming in from mobile edits. They work quite well! I’ve put them to the task, and in theory they can even handle multiple actors working on the data set simultaneously. You still want to avoid conflicts where you can, but when they happen resolution can be done in the comfort of the project interface rather than hacking at internal files.
So as far as having some external system trying to replicate that blindly, it’s probably best we don’t have an official “intergration” feature set, as it might send the wrong message about what it could provide. Most people are going to be looking to CVS for, well… concurrency. 
Yup. i was one of the early agitators for integration with source control, and it wasn’t until I’d worked with Scrivener for a while and figured out more about how it worked internally that I realized what a very bad idea that would be even in a single-user setting.
– related to version control, collaboration with other writers, and how this works in Scrivener … is this use of XML & RTF how Scrivener correctly imports MS Word documents?
– will the upcoming changes with the Windows 3.0 version mean that Scrivener will allow us to actually control branching/forking & merging? OR is this due for a later release? OR is this not in the roadmap?
– will this also allow us to collaborate with others, so that I can not only see who has done what edits and control all the merging … but also enabling plugins/mods to be written for event hooks in scrivener, so that we can ( for example ) get data about contributions that are a consequence of the merge – ie: how many hours writing and how many words were actually written by specific people, and which actually get used in the final version vs. total writing done by each person on that branch ( or multiple branches ) whether used or not … that kind of thing ( I’m thinking project management here )
Is there a diagram by any chance showing the rough roadmap?
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. 
OK, that’s kinda what I thought it would be, thanks for the in-depth answer … it’s that tragic side of the computer software world really – ie: there’s 20 different tools that each separately handle something you want to do perfectly, but trying to get them all into an integrated framework is like wishing for politicians that aren’t corrupt :mrgreen: … well, it sounds like at least v3.0 will be good enough for most scenarios, so long as everyone working on a project agrees to a style guide to keep those conflicts to a minimum.