As for text editing, maybe we could restrict the lock just to a neighbouring of 1 or 2 words from the point where the other user is editing. Maybe those 2 words would be the only highlighted ones.
On Thursday 15 July 2010 06:52:06 iberlynx wrote: > 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 <[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. > > > > > _______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
