23 May
2019
23 May
'19
9:56 a.m.
On 23 May 2019, at 09:31, Simon Urli
<simon.urli(a)xwiki.com> wrote:
On 23/05/2019 09:22, Vincent Massol wrote:
From a technical point you’re right. However, this is exactly the situation we had before
you started implementing the conflict window: the last user who saves overwrite any
previous changes that happened after he started editing. And if you remember Ludovic
raised this problem since he had users who complained to him about “data loss”. From their
POV, the content saved by the user who got overwritten was lost.
Anyway, we agree that option 1 is not great so we’re good :)
Thanks
-Vincent
Hi Simon,
I'm just stating about the current implementation of the document merge here.
It's just how it works right now. And if you use the version the user is trying to
save as the fallback strategy (which was what we discussed for option 1), you'd never
get a data loss: all versions would be stored in revisions. On 23 May 2019, at 09:14, Simon Urli
<simon.urli(a)xwiki.com> wrote:
Hi Vincent, all,
On 22/05/2019 11:03, Vincent Massol wrote:
That’s really a bad idea IMO. By definition, a conflict is … a conflict…
there’s no way to merge that automatically or it’s not a conflict…. If you do, then you
have data loss. Which is not acceptable (it’s the worse thing that can happen and exactly
what we’re trying to avoid with this feature! ;)). The user has to be presented the
conflict and needs to be asked what he wants to loose: his data or the data from the last
person who saved. And give him a solution to store his content so that he can merge it
manually line by line later on (save his content on another special page, in memory
(risky), etc). Hi Simon,
> On 22 May 2019, at 10:45, Simon Urli <simon.urli(a)xwiki.com> wrote:
>
> Hi everyone,
>
> I'm working on the merge on save for the roadmap of 11.5 and I need some decision
to be taken.
>
> The main idea of the merge on save, is to try to merge users work in case of save
conflict. Knowing that the merge might led to merge conflict in case of edits on the same
places. Those merge conflict can be tackled automatically, but a priority will be then
given to one version over another.
>
> I first propose to add an option in user profile, so users would have the possibility
to choose between:
> 1. Always merge automatically the work, even in case of merge conflict
I don’t understand this part. If there’s a conflict it means it cannot be merged… So
would it do? Take latest version and overwrite previous version?
We have an automatic fallback in case of conflict, for which we can choose the strategy:
use current, previous or next version. By default the strategy is to take the current
version.
So the merge is never stucked in case of conflict, by default it returns the current
version.
Now I agree with you that option 1 is not a good idea, as I said in my first mail I'm
afraid that the user would feel the same as before the warning conflict window.
Simon
And in the next version, we’ll need to ask him
this but line by line so that it’s not all or nothing.
Do you agree?
Thanks
-Vincent
>
> Simon
>>> 2. Always merge automatically, but ask what to do in case of merge conflict
>>> 3. Always ask what to do in case of save conflict
>>>
>>> Now the question is: what should be the default option?
>> Certainly not 1! 2 is really the best to me.
>> Thanks
>> -Vincent
>>> Option 1 looks like a good fit for decreasing the number of clicks to do, but
I'm a bit afraid that in case of conflict they would have the same feeling as before
the warning conflict window: i.e. to loose some part of their work.
>>>
>>> WDYT?
>>>
>>> Simon
>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> simon.urli(a)xwiki.com
>>> More about us at http://www.xwiki.com
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> simon.urli(a)xwiki.com
> More about us at http://www.xwiki.com
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com