[Proposal] Merge on save

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Proposal] Merge on save

Simon Urli
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
   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?

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
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator
Hi Simon,

> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
> [hidden email]
> More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Ecaterina Moraru (Valica)
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.

Also the options are not clear to me: like 2: automatically merge, but ask.
Well is automatically or not?
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?

Thanks,
Caty

On Wed, May 22, 2019 at 12:04 PM Vincent Massol <[hidden email]> wrote:

> Hi Simon,
>
> > On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
> > [hidden email]
> > More about us at http://www.xwiki.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Simon Urli
In reply to this post by vmassol
Hi Vincent, all,

On 22/05/2019 11:03, Vincent Massol wrote:

> Hi Simon,
>
>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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.

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
>> [hidden email]
>> More about us at http://www.xwiki.com
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator
Hi Simon,

> On 23 May 2019, at 09:14, Simon Urli <[hidden email]> wrote:
>
> Hi Vincent, all,
>
> On 22/05/2019 11:03, Vincent Massol wrote:
>> Hi Simon,
>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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).

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
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Simon Urli
In reply to this post by Ecaterina Moraru (Valica)
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.

Simon

>
> Thanks,
> Caty
>
> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <[hidden email]> wrote:
>
>> Hi Simon,
>>
>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>>
>>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Simon Urli
In reply to this post by vmassol


On 23/05/2019 09:22, Vincent Massol wrote:

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

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator
In reply to this post by Simon Urli


> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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.

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). And when he saves, the merge is done then.

WDYT?

Thanks
-Vincent

>
> Simon
>> Thanks,
>> Caty
>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <[hidden email]> wrote:
>>> Hi Simon,
>>>
>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>>
>>>
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Simon Urli


On 23/05/2019 09:31, Vincent Massol wrote:

>
>
>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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".

>
> 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). 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 :)

Simon

> WDYT?
>
> Thanks
> -Vincent
>
>>
>> Simon
>>> Thanks,
>>> Caty
>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <[hidden email]> wrote:
>>>> Hi Simon,
>>>>
>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>> [hidden email]
>>>>> More about us at http://www.xwiki.com
>>>>
>>>>
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator
In reply to this post by Simon Urli


> On 23 May 2019, at 09:31, Simon Urli <[hidden email]> wrote:
>
>
>
> On 23/05/2019 09:22, Vincent Massol wrote:
>> Hi Simon,
>>> On 23 May 2019, at 09:14, Simon Urli <[hidden email]> wrote:
>>>
>>> Hi Vincent, all,
>>>
>>> On 22/05/2019 11:03, Vincent Massol wrote:
>>>> Hi Simon,
>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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.

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

>
> 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
>>>>> [hidden email]
>>>>> More about us at http://www.xwiki.com
>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator
In reply to this post by Simon Urli


> On 23 May 2019, at 09:43, Simon Urli <[hidden email]> wrote:
>
>
>
> On 23/05/2019 09:31, Vincent Massol wrote:
>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]> wrote:
>>>>> Hi Simon,
>>>>>
>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>>> [hidden email]
>>>>>> More about us at http://www.xwiki.com
>>>>>
>>>>>
>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator


> On 23 May 2019, at 10:00, Vincent Massol <[hidden email]> wrote:
>
>
>
>> On 23 May 2019, at 09:43, Simon Urli <[hidden email]> wrote:
>>
>>
>>
>> On 23/05/2019 09:31, Vincent Massol wrote:
>>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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

It needs some refresh from Caty since we changed the buttons for ex but it’s a start.

Thanks
-Vincent

>
> Thanks
> -Vincent
>
>>
>> Simon
>>
>>> WDYT?
>>> Thanks
>>> -Vincent
>>>>
>>>> Simon
>>>>> Thanks,
>>>>> Caty
>>>>> On Wed, May 22, 2019 at 12:04 PM Vincent Massol <[hidden email]> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>>>> [hidden email]
>>>>>>> More about us at http://www.xwiki.com
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Simon Urli
In reply to this post by vmassol
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.

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 <[hidden email]> wrote:
>>
>>
>>
>> On 23/05/2019 09:31, Vincent Massol wrote:
>>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>>>> [hidden email]
>>>>>>> More about us at http://www.xwiki.com
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Thomas Mortagne
Administrator
On Thu, May 23, 2019 at 11:10 AM Simon Urli <[hidden email]> 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 <[hidden email]> wrote:
> >>
> >>
> >>
> >> On 23/05/2019 09:31, Vincent Massol wrote:
> >>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]> wrote:
> >>>>>> Hi Simon,
> >>>>>>
> >>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
> >>>>>>> [hidden email]
> >>>>>>> More about us at http://www.xwiki.com
> >>>>>>
> >>>>>>
> >>>>
> >>>> --
> >>>> Simon Urli
> >>>> Software Engineer at XWiki SAS
> >>>> [hidden email]
> >>>> More about us at http://www.xwiki.com
> >>
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> [hidden email]
> >> More about us at http://www.xwiki.com
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator


> On 23 May 2019, at 11:37, Thomas Mortagne <[hidden email]> wrote:
>
> On Thu, May 23, 2019 at 11:10 AM Simon Urli <[hidden email]> 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)

Yes

> 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.

Not sure what you mean since we agreed so far that option 1 is a bad idea and thus there’s no automatic “resolution" of conflicts (ie data loss from user POV). If you mean that the user can choose to discard his own data or choose to overwrite previous author’s data, then yes, I agree. It’s probably a wording issue but in this case I don’t consider it to be an “automatic merge” since there’s no merge and it's not automatic.

Thanks
-Vincent

>
>>
>> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On 23/05/2019 09:31, Vincent Massol wrote:
>>>>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>>>>>> [hidden email]
>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Simon Urli
>>>>>> Software Engineer at XWiki SAS
>>>>>> [hidden email]
>>>>>> More about us at http://www.xwiki.com
>>>>
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>>
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>
>
>
> --
> Thomas Mortagne

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Ecaterina Moraru (Valica)
In reply to this post by Simon Urli
On Thu, May 23, 2019 at 12:10 PM Simon Urli <[hidden email]> 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.
>

I don't agree about the all-or-nothing, since I would prefer to accept what
we can, warn on conflicts.
We should show a resolution conflict when the conflict is on the same line.
Auto-merge the rest.


>
> 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.
>

I don't like the option in the profile. IMO we should decide on the
behavior and apply it for all users. Edit is a core feature, conflicts
again are part of this kind of interaction.


>
> 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.
>

On "Save&View" we can increase the timeout for the notification.
The notification could mention also the magnitude: "Saved. Auto-merged 10
conflicts."
If cannot save, show the conflict modal.


>
> 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
>

This mockup might not help, but is something I had in mind that I want to
share:
https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolor.png

Ideally I would like to see real time, if not the exact changes, but at
least the lines affected by the current editor.

Thanks,
Caty


>
> 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 <[hidden email]> wrote:
> >>
> >>
> >>
> >> On 23/05/2019 09:31, Vincent Massol wrote:
> >>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]>
> wrote:
> >>>>>> Hi Simon,
> >>>>>>
> >>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
> >>>>>>> [hidden email]
> >>>>>>> More about us at http://www.xwiki.com
> >>>>>>
> >>>>>>
> >>>>
> >>>> --
> >>>> Simon Urli
> >>>> Software Engineer at XWiki SAS
> >>>> [hidden email]
> >>>> More about us at http://www.xwiki.com
> >>
> >> --
> >> Simon Urli
> >> Software Engineer at XWiki SAS
> >> [hidden email]
> >> More about us at http://www.xwiki.com
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com
>
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator


> On 23 May 2019, at 16:00, Ecaterina Moraru (Valica) <[hidden email]> wrote:

[snip]

> This mockup might not help, but is something I had in mind that I want to
> share:
> https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolor.png
>
> Ideally I would like to see real time, if not the exact changes, but at
> least the lines affected by the current editor.

That’s a different beast. Also I don’t recall the exact arguments but some devs said in the past that realtime wasn’t going to solve all needs and that we might needing both merge-on-save and realtime. In any case they’re separate and I don’t think we should wait for realtime FTM and it’s good to progress on save-on-merge.

Thanks
-Vincent

[snip]
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Simon Urli
In reply to this post by vmassol


On 23/05/2019 12:15, Vincent Massol wrote:

>
>
>> On 23 May 2019, at 11:37, Thomas Mortagne <[hidden email]> wrote:
>>
>> On Thu, May 23, 2019 at 11:10 AM Simon Urli <[hidden email]> 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)
>
> Yes
>
>> 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.
>
> Not sure what you mean since we agreed so far that option 1 is a bad idea and thus there’s no automatic “resolution" of conflicts (ie data loss from user POV). If you mean that the user can choose to discard his own data or choose to overwrite previous author’s data, then yes, I agree. It’s probably a wording issue but in this case I don’t consider it to be an “automatic merge” since there’s no merge and it's not automatic.

So here by "all or nothing" I meant "not allowing choice conflict by
conflict, but only allow choice for the whole document": as specified by
Vincent, the choice would be indeed to discard his own data or choose to
overwrite previous author's data.

The reason why I propose that is just a calendar reason: I'm afraid that
the UI work would be complicated to achieve for 11.5 with the other
features. That's why I propose to first concentrate on this, and then to
improve with the resolution conflict by conflict.

Simon

>
> Thanks
> -Vincent
>
>>
>>>
>>> 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 <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 23/05/2019 09:31, Vincent Massol wrote:
>>>>>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Simon Urli
>>>>>>> Software Engineer at XWiki SAS
>>>>>>> [hidden email]
>>>>>>> More about us at http://www.xwiki.com
>>>>>
>>>>> --
>>>>> Simon Urli
>>>>> Software Engineer at XWiki SAS
>>>>> [hidden email]
>>>>> More about us at http://www.xwiki.com
>>>>
>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>>
>>
>>
>> --
>> Thomas Mortagne
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

Simon Urli
In reply to this post by Ecaterina Moraru (Valica)


On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:

> On Thu, May 23, 2019 at 12:10 PM Simon Urli <[hidden email]> 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.
>>
>
> I don't agree about the all-or-nothing, since I would prefer to accept what
> we can, warn on conflicts.
> We should show a resolution conflict when the conflict is on the same line.
> Auto-merge the rest.

Apparently I wasn't clear about my "all or nothing" feature. For me it
only concern the resolution of the merge conflicts, but the choice made
apply to ALL conflict of the document. That's what I meant.

>
>
>>
>> 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.
>>
>
> I don't like the option in the profile. IMO we should decide on the
> behavior and apply it for all users. Edit is a core feature, conflicts
> again are part of this kind of interaction.
>

So you'd go with a -1 for this option?

>
>>
>> 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.
>>
>
> On "Save&View" we can increase the timeout for the notification.
> The notification could mention also the magnitude: "Saved. Auto-merged 10
> conflicts."
> If cannot save, show the conflict modal.
>

How would you quantify this magnitude? The number of versions between
the two saves? What about minor/major versions? It looks a bit fuzzy to me.

About increasing the notif timeout in case of Save&View I'm not
convinced: you're suppose to be immediately redirected to the view page
in case of Save&View, so making the user wait on a notif doesn't look
very nice.

Simon

>
>>
>> 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
>>
>
> This mockup might not help, but is something I had in mind that I want to
> share:
> https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolor.png
>
> Ideally I would like to see real time, if not the exact changes, but at
> least the lines affected by the current editor.
>
> Thanks,
> Caty
>
>
>>
>> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>>
>>>> On 23/05/2019 09:31, Vincent Massol wrote:
>>>>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]>
>> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>>>>>> [hidden email]
>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Simon Urli
>>>>>> Software Engineer at XWiki SAS
>>>>>> [hidden email]
>>>>>> More about us at http://www.xwiki.com
>>>>
>>>> --
>>>> Simon Urli
>>>> Software Engineer at XWiki SAS
>>>> [hidden email]
>>>> More about us at http://www.xwiki.com
>>>
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Merge on save

vmassol
Administrator


> On 23 May 2019, at 17:33, Simon Urli <[hidden email]> wrote:
>
>
>
> On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
>> On Thu, May 23, 2019 at 12:10 PM Simon Urli <[hidden email]> 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.
>>>
>> I don't agree about the all-or-nothing, since I would prefer to accept what
>> we can, warn on conflicts.
>> We should show a resolution conflict when the conflict is on the same line.
>> Auto-merge the rest.
>
> Apparently I wasn't clear about my "all or nothing" feature. For me it only concern the resolution of the merge conflicts, but the choice made apply to ALL conflict of the document. That's what I meant.
>>>
>>> 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.
>>>
>> I don't like the option in the profile. IMO we should decide on the
>> behavior and apply it for all users. Edit is a core feature, conflicts
>> again are part of this kind of interaction.
>
> So you'd go with a -1 for this option?
>>>
>>> 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.
>>>
>> On "Save&View" we can increase the timeout for the notification.
>> The notification could mention also the magnitude: "Saved. Auto-merged 10
>> conflicts."
>> If cannot save, show the conflict modal.
>
> How would you quantify this magnitude? The number of versions between the two saves? What about minor/major versions? It looks a bit fuzzy to me.
>
> About increasing the notif timeout in case of Save&View I'm not convinced: you're suppose to be immediately redirected to the view page in case of Save&View, so making the user wait on a notif doesn't look very nice.

I don’t understand why we’d need this at all since if we agree with the poll it’s not needed.

Thanks
-Vincent

>
> Simon
>>>
>>> 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
>>>
>> This mockup might not help, but is something I had in mind that I want to
>> share:
>> https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolor.png
>> Ideally I would like to see real time, if not the exact changes, but at
>> least the lines affected by the current editor.
>> Thanks,
>> Caty
>>>
>>> 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 <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 23/05/2019 09:31, Vincent Massol wrote:
>>>>>>> On 23 May 2019, at 09:25, Simon Urli <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>>> On 22 May 2019, at 10:45, Simon Urli <[hidden email]> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> More about us at http://www.xwiki.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Simon Urli
>>>>>>> Software Engineer at XWiki SAS
>>>>>>> [hidden email]
>>>>>>> More about us at http://www.xwiki.com
>>>>>
>>>>> --
>>>>> Simon Urli
>>>>> Software Engineer at XWiki SAS
>>>>> [hidden email]
>>>>> More about us at http://www.xwiki.com
>>>>
>>>
>>> --
>>> Simon Urli
>>> Software Engineer at XWiki SAS
>>> [hidden email]
>>> More about us at http://www.xwiki.com
>>>
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com

12