On 23/05/2019 09:22, Vincent Massol wrote:
Hi Simon,
On 23 May 2019, at 09:14, Simon Urli <simon.u...@xwiki.com> wrote:
Hi Vincent, all,
On 22/05/2019 11:03, Vincent Massol wrote:
Hi Simon,
On 22 May 2019, at 10:45, Simon Urli <simon.u...@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.
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).
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.
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.u...@xwiki.com
More about us at http://www.xwiki.com
--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com
--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com
