> On 23 May 2019, at 09:43, Simon Urli <[email protected]> wrote:
>
>
>
> On 23/05/2019 09:31, Vincent Massol wrote:
>>> On 23 May 2019, at 09:25, Simon Urli <[email protected]> wrote:
>>>
>>> Hi Caty,
>>>
>>> On 22/05/2019 14:51, Ecaterina Moraru (Valica) wrote:
>>>> I'm not sure I agree about this profile option.
>>>> Indeed we want to make things as simple as possible and having conflict
>>>> resolutions can be scary, still, there is no way an user could take this
>>>> decision in advance.
>>>> Users will want to have control over what they do and at least know
>>>> something went wrong. We cannot automatically merge, without any warning,
>>>> since users will immediately see that their work was changed. It will be
>>>> reported as a bug (in case they notice it) and they will expect to be able
>>>> to recover the work.
>>>> I can't think of a case when an user would not care about the changes and
>>>> the result.
>>>
>>> Let say that a document has 2 sections, and a user is editing section 1,
>>> while the other is editing section 2. The merge should work properly
>>> without any conflict.
>>> I don't really see the point of asking by default the second user if he's
>>> ok to merge his work on section 1 with what has been saved on section 2.
>>> On the contrary I feel it could be scary for the basic users to see this
>>> kind of message and it decreases the easiness of using XWiki IMO.
>>>
>>>> Also the options are not clear to me: like 2: automatically merge, but ask.
>>>> Well is automatically or not?
>>>
>>> It's automatic but as you mentioned just after, in case of changes are made
>>> on the same line there is a conflict that needs to be solved. That's what I
>>> meant by "ask in case of merge conflict".
>>>
>>> On the contrary option 1 was a fully automatic merge, with a predefined
>>> strategy to choose one version over another in case of conflict.
>>>
>>>> We need to ask for resolution only if the changes are on the same line,
>>>> besides this, we should try to automatically merge, but provide the info to
>>>> the user that we did that. Instead of the normal Save message, we could say
>>>> that we performed a Merged Save. And in the history I would expect to be
>>>> able to see what lines were added by what users, just in case something
>>>> went wrong. We are lucky that we have the Blame view :)
>>>> So not sure we need a configurable option in profile. We just need to
>>>> decide on the 'default' and implement that. We keep adding options that
>>>> only increase the complexity of the product and we never get to test all
>>>> the possible mixes and configurations.
>>>> So what are the use cases when we would need this option in the profile?
>>>
>>> As I said above I personally don't see the point of always displaying the
>>> merge diff especially for basic users when there's no conflict. Now I
>>> really think that some users would want that, that's why I proposed the
>>> profile option.
>> I agree that option 3 is not great as it gets in the way. Now it could be
>> interesting for the user to know it happened. Maybe some fleeting
>> notifications at the bottom of the screen or some info added to the commit
>> message or some visual info when you’re in edit mode and before you press
>> save.
>
> So in case of "Save&Continue" it's quite easy to change the "Saved"
> notification message by another one. I'm not quite sure how to inform the
> user about the merge if he cliks on "Save&View”.
By implementing the part below :) ie by providing this info continuously before
he clicks any save button.
>
>> Ideally I’d like that we poll regularly to see if there have been changes
>> and display some icon if there are with the ability for the current user to
>> click and see the diffs with his version, and if there’s a conflict, that a
>> visible message is displayed on the screen (but without interrupting of his
>> typing).
More details: when there’s a conflict, clicking the message/button would show
the diff and the conflict.
>> And when he saves, the merge is done then.
>
> I like the idea, now would that be enough to inform about the performed
> merge? If we go in that direction I'd need some design proposal for the UI
> @Caty :)
Yes we need to find where to put that information.
BTW, even better, we should ideally also display the icons of the users who are
editing the same doc and/or who have saved content after the current user
started editing.
And we already have a design page for this ;) We called it “collaborative
editing”:
https://design.xwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing
Thanks
-Vincent
>
> Simon
>
>> WDYT?
>> Thanks
>> -Vincent
>>>
>>> Simon
>>>> Thanks,
>>>> Caty
>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <[email protected]> wrote:
>>>>> Hi Simon,
>>>>>
>>>>>> On 22 May 2019, at 10:45, Simon Urli <[email protected]> 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?
>>>>>
>>>>>> 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
>>>>>> [email protected]
>>>>>> More about us at http://www.xwiki.com
>>>>>
>>>>>
>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> [email protected]
>>> More about us at http://www.xwiki.com
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [email protected]
> More about us at http://www.xwiki.com
