staniek at kde.org
Wed Jul 14 23:22:57 UTC 2010
On 14 July 2010 22:43, iberlynx <iberlynx at lavabit.com> wrote:
> 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?
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
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
Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
KDE Software Development Platform on MS Windows (http://windows.kde.org)
More information about the Owncloud