On 14 July 2010 22:43, iberlynx <[email protected]> wrote: > Hi, > > you say git is not the way to go because you only consider it in the > pessimistic approach. But have you thought of using git or some similarly > powerful diff engine with an optimistic approach? > > Let me give you my proposal: > Every user action be it a single character change or a block change or a > formatting change is automatically git-committed and git-pushed to the other > users, which would automatically git-merge the changes as git does so well. > So no locking would be required, hence no latency problem. > (This would additionally solve the problem you stated with non atomic > changes!) > The only obstacle that I foresee is that IIRC git doesn't merge changes on > the same line, but I'm sure that there's a way to tailor git's algorithm for > this specific use-case! > > Am I just being my usual self, and this is a crazy idea? Or does it make > sense to you as well?
Hi; Just a though: Do we need as heavy waepon as git for this simple non-conflicing case? As you admitted, nontrivial (real) cases need extensions/hooks to git, the same that would also be needed for other version control tools. Is there anything special about git that helps in collaborative editing of documents? Regarding extensions for merging at text level, please note that git or similar tools are for source code, character-based media; for structured media even merging tables is nontrivial in general case. IMHO it's worth to consider locking feature at local level (paragraph or table) than accepting any edits and then trying to merge. -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org) KDE Software Development Platform on MS Windows (http://windows.kde.org) _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
