On Thu, May 23, 2019 at 11:10 AM Simon Urli <simon.u...@xwiki.com> wrote: > > So trying to sum up the discussion to see if we all agree. > > All the above is in the case of a save conflict: > > 1. Default behaviour for all users is to try an automatic merge, and to > display a window conflict resolution in case of merge conflict. The > conflict resolution is an all-or-nothing based, allowing to choose a > version over another.
Not sure what you mean by "all-or-nothing" (I guess you just mean that you can't choose a line over another) but to be safe I prefer to repeat that among the possible choices the user can make in the windows there should be the proposed automatic merge. > > 2. There is an option in the user profile to be able to always see the > diff in case of save conflict, to accept or not the merge, even when > there's no conflict. > > 3. When a user save with a merge, the notification message displays that > it's a merge save. It means that user clicking on "save&view" might miss it. > > Those are the first three priority points. The following points are > important too, but might not be finished in 11.5. > > 4. If another user saved a document that I'm editing, I have a > notification in the editor and I can click on it to see the diff/conflicts > > 5. The conflict resolution is line-by-line based. > > WDYT? > Simon > > On 23/05/2019 10:00, Vincent Massol wrote: > > > > > >> On 23 May 2019, at 09:43, Simon Urli <simon.u...@xwiki.com> wrote: > >> > >> > >> > >> On 23/05/2019 09:31, Vincent Massol wrote: > >>>> On 23 May 2019, at 09:25, Simon Urli <simon.u...@xwiki.com> 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 <vinc...@massol.net> > >>>>> 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? > >>>>>> > >>>>>>> 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 > > > > -- > Simon Urli > Software Engineer at XWiki SAS > simon.u...@xwiki.com > More about us at http://www.xwiki.com -- Thomas Mortagne
