[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Owncloud] Suggestions
From:       iberlynx <iberlynx () lavabit ! com>
Date:       2010-07-15 5:52:06
Message-ID: 201007150652.07575.iberlynx () lavabit ! com
[Download RAW message or body]

Sure, I'm not saying git is imperative, although git IIRC merges all kinds of text, \
not just code, and office (XML) files are just text wright? And is pretty fast. My \
point was that IMHO, there should be no need to slow the interface down because of \
locking, since we can fix the inconsistencies with an intelligent merge algorithm. I \
agree with you that a context (from structured media) aware (something like the \
duchain of kdevelop) solution would simplify things a bit. But still i think git is \
wright in not merging within the same line, because if two people do opposing changes \
in the same line, we've got a problem. Maybe the solution lies with the standard \
highlighting the line that the other user is editing, which is already an intuitive \
visual deterrent for editing that line, combined with the locking of only that \
highlighted line. So if the user for example tries to change formatting of a whole \
paragraph which contains said highlighted line (other user is editing), the interface \
just flashes and gives out some kind of warning that you can't edit the same line \
other users are editing remotely, and asks: do you wish to 1. don't apply formatting, \
2. apply formatting to the rest of the lines, 3. suggest the other user to apply \
formatting to the whole block? The rest of the text should be totally free to edit \
everything with no latency at all.

what do you say?

On Thursday 15 July 2010 00:22:57 Jaroslaw Staniek wrote:
> On 14 July 2010 22:43, iberlynx <iberlynx@lavabit.com> 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.
> 
> 

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]