Re: [xwiki-devs] [Proposal] Merge on save

[Marius Dumitru Florea]

On Mon, May 27, 2019 at 5:25 PM Eduard Moraru  wrote:

> Hi,
>
> I feel we're over-engineering things a bit, at least for a fist version. My
> feeling is that the approach is to go with an UI-first version (the whole
> talk about being able to choose "mine" vs "their" versions) and only then,
> at a later point, coming back to a text-based version that allows you to
> fix the details. Why not go the other way around, in a simpler and already
> familiar (to some at least) yet flexible solution of starting with the
> text-based version, since



> we are editing wiki syntax after all?
>

Simple users that are using the WYSIWYG editor are not using the wiki
syntax directly. It's scary enough for them to see the changes (in the
History tab for instance) on wiki syntax. You now want them to fix a merge
conflict in wiki syntax? I feel it's too much.


>
> IMO, the easiest thing we could do is that, when a save is attempted, a
> merge should be attempted first. If no conflict occurs and the merge can be
> done automatically, the save should be done on the DB as well and



> the user should not perceive anything, thus not affecting his flow.
>

I don't agree. I think we should use a different **notification** message
than "Saved". I think it's useful to know that a merge was needed, even if
one could be done automatically.


>
> Note: I hope we are all on the same page when I say that the merge conflict
> resolution should target/work on wiki syntax in the UI as well.
>

If you're referring to the diffs, then yes, we don't have visual diffs ATM
(on HTML) and even if we had, a visual diff might hide some changes and
thus I don't think it would be suited for a merge conflict resolution. But
showing the wiki syntax diff and giving the (simple) user some action
buttons is definitely easier (for they) than to ask them to fix the merge
conflict by editing the wiki syntax directly.

Thanks,
Marius


>
> If, however, conflicts do occur, the save does not go to the DB. Instead:
> * If it was a save&continue, the UI should inform the user (popup/bottom
> screen notification) that the save failed because of a conflict and offer
> the possibility to keep editing or resolve the conflict
> * If it was a save&view (or if the user clicked "resolve conflict" after a
> failed save&continue), the UI should reload the (wiki) editor with the
> entire merged content that will include the conflicts in a way that is (at
> least in the first implementation) similar to how git conflicts are
> displayed in a file, i.e. clearly marked in the content (where the conflict
> starts and ends), showing your version vs the version that is currently on
> the server (in the DB). Example (with html, but imagine wiki syntax here
> and we could use something better than "HEAD", etc.):
>
> https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png
>
> An improved version (iteration) of this could then be to use something like
> CodeMirror's "merge" addon (since we already use CodeMirror in the syntax
> highlighting application). It supports 2-way or 3-way display and live diff
> computation between the versions, synchronized scrollbars, and other neat
> stuff: https://codemirror.net/demo/merge.html We could decide if in "our"
> version we include the user's original version OR if we put directly the
> merged version (where the auto-merges are already applied) OR if we have a
> button under the user's original version to perform auto-merge on request,
> leaving just the remaining conflicts to be handled by the user. Finally,
> when save&view is pressed in this mode (note: probably we need to disable
> save&continue so that the "conflict resolution" action is "atomic", i.e.
> without leaving the content in an unfinished merge state), whatever the
> edited version is will overwrite the DB version of the document (i.e. force
> with whatever it contains).
>
> WDYT?
>
> Thanks,
> Eduard
>
> On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) <
> vali...@gmail.com>
> wrote:
>
> > On Thu, May 23, 2019 at 6:33 PM Simon Urli  wrote:
> >
> > >
> > >
> > > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
> > > > On Thu, May 23, 2019 at 12:10 PM Simon Urli 
> > > 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

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

On 27/05/2019 17:04, Eduard Moraru wrote:
Also, there is the possibility of having to go though the conflict 
resolution screen multiple times if, whenever trying to finish it and 
press save, a new change was done in the background user, generating a 
conflict with the version you have just resolved. If it's a very popular 
page that users are constantly editing generally on the same places of 
the document, this could get a bit annoying the more time you spend in 
edit mode :)


I think that's exactly why Vincent proposed to have a way to directly 
know when you're editing if someone made a save on the same page: so you 
can know that there's a risk that you got a conflict.


On Mon, May 27, 2019 at 5:25 PM Eduard Moraru > wrote:


Hi,

I feel we're over-engineering things a bit, at least for a fist
version. My feeling is that the approach is to go with an UI-first
version (the whole talk about being able to choose "mine" vs "their"
versions) and only then, at a later point, coming back to a
text-based version that allows you to fix the details. Why not go
the other way around, in a simpler and already familiar (to some at
least) yet flexible solution of starting with the text-based
version, since we are editing wiki syntax after all?

IMO, the easiest thing we could do is that, when a save is
attempted, a merge should be attempted first. If no conflict occurs
and the merge can be done automatically, the save should be done on
the DB as well and the user should not perceive anything, thus not
affecting his flow.

Note: I hope we are all on the same page when I say that the merge
conflict resolution should target/work on wiki syntax in the UI as well.

If, however, conflicts do occur, the save does not go to the DB.
Instead:
* If it was a save&continue, the UI should inform the user
(popup/bottom screen notification) that the save failed because of a
conflict and offer the possibility to keep editing or resolve the
conflict
* If it was a save&view (or if the user clicked "resolve conflict"
after a failed save&continue), the UI should reload the (wiki)
editor with the entire merged content that will include the
conflicts in a way that is (at least in the first implementation)
similar to how git conflicts are displayed in a file, i.e. clearly
marked in the content (where the conflict starts and ends), showing
your version vs the version that is currently on the server (in the
DB). Example (with html, but imagine wiki syntax here and we could
use something better than "HEAD", etc.):

https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png

An improved version (iteration) of this could then be to use
something like CodeMirror's "merge" addon (since we already use
CodeMirror in the syntax highlighting application). It supports
2-way or 3-way display and live diff computation between the
versions, synchronized scrollbars, and other neat stuff:
https://codemirror.net/demo/merge.html We could decide if in "our"
version we include the user's original version OR if we put directly
the merged version (where the auto-merges are already applied) OR if
we have a button under the user's original version to perform
auto-merge on request, leaving just the remaining conflicts to be
handled by the user. Finally, when save&view is pressed in this mode
(note: probably we need to disable save&continue so that the
"conflict resolution" action is "atomic", i.e. without leaving the
content in an unfinished merge state), whatever the edited version
is will overwrite the DB version of the document (i.e. force with
whatever it contains).

WDYT?

Thanks,
Eduard

On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica)
mailto:vali...@gmail.com>> wrote:

On Thu, May 23, 2019 at 6:33 PM Simon Urli mailto:simon.u...@xwiki.com>> wrote:

 >
 >
 > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
 > > On Thu, May 23, 2019 at 12:10 PM Simon Urli
mailto:simon.u...@xwiki.com>>
 > wrote:
 > >
 > >> So trying to sum up the discussion to see if we all agree.
 > >>
 > >> All the above is in the case of a save conflict:
 > >>
 > >> 1. Default behaviour for all users is to try an automatic
merge, and to
 > >> display a window conflict resolution in case of merge
conflict. The
 > >> conflict resolution is an all-or-nothing based, allowing
to choose a
 > >> version over another.
 > >>
 > >
 > > 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 resolut

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

Hi Edy, all,

On 27/05/2019 16:25, Eduard Moraru wrote:

Hi,

I feel we're over-engineering things a bit, at least for a fist version. 
My feeling is that the approach is to go with an UI-first version (the 
whole talk about being able to choose "mine" vs "their" versions) and 
only then, at a later point, coming back to a text-based version that 
allows you to fix the details. Why not go the other way around, in a 
simpler and already familiar (to some at least) yet flexible solution of 
starting with the text-based version, since we are editing wiki syntax 
after all?


IMO, the easiest thing we could do is that, when a save is attempted, a 
merge should be attempted first. If no conflict occurs and the merge can 
be done automatically, the save should be done on the DB as well and the 
user should not perceive anything, thus not affecting his flow.


we all agree on that so far.


Note: I hope we are all on the same page when I say that the merge 
conflict resolution should target/work on wiki syntax in the UI as well.


I hope too, for me it should work in any editor: WYSIWYG/inline/wiki/etc.



If, however, conflicts do occur, the save does not go to the DB. Instead:
* If it was a save&continue, the UI should inform the user (popup/bottom 
screen notification) that the save failed because of a conflict and 
offer the possibility to keep editing or resolve the conflict
* If it was a save&view (or if the user clicked "resolve conflict" after 
a failed save&continue), the UI should reload the (wiki) editor with the 
entire merged content that will include the conflicts in a way that is 
(at least in the first implementation) similar to how git conflicts are 
displayed in a file, i.e. clearly marked in the content (where the 
conflict starts and ends), showing your version vs the version that is 
currently on the server (in the DB). Example (with html, but imagine 
wiki syntax here and we could use something better than "HEAD", etc.): 
https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png




So for me that is specifically *not* a first version proposal :)
I won't be able to do such work properly in one release, for sure.
Hence my proposal to reuse the work already done with the conflict 
window, and to reuse it for the merge conflict window.


Now I agree it's a really good idea and it could be a good direction for 
next iterations.


Simon

An improved version (iteration) of this could then be to use something 
like CodeMirror's "merge" addon (since we already use CodeMirror in the 
syntax highlighting application). It supports 2-way or 3-way display and 
live diff computation between the versions, synchronized scrollbars, and 
other neat stuff: https://codemirror.net/demo/merge.html We could decide 
if in "our" version we include the user's original version OR if we put 
directly the merged version (where the auto-merges are already applied) 
OR if we have a button under the user's original version to perform 
auto-merge on request, leaving just the remaining conflicts to be 
handled by the user. Finally, when save&view is pressed in this mode 
(note: probably we need to disable save&continue so that the "conflict 
resolution" action is "atomic", i.e. without leaving the content in an 
unfinished merge state), whatever the edited version is will overwrite 
the DB version of the document (i.e. force with whatever it contains).


WDYT?

Thanks,
Eduard

On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) 
mailto:vali...@gmail.com>> wrote:


On Thu, May 23, 2019 at 6:33 PM Simon Urli mailto:simon.u...@xwiki.com>> wrote:

 >
 >
 > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
 > > On Thu, May 23, 2019 at 12:10 PM Simon Urli
mailto:simon.u...@xwiki.com>>
 > wrote:
 > >
 > >> So trying to sum up the discussion to see if we all agree.
 > >>
 > >> All the above is in the case of a save conflict:
 > >>
 > >> 1. Default behaviour for all users is to try an automatic
merge, and to
 > >> display a window conflict resolution in case of merge
conflict. The
 > >> conflict resolution is an all-or-nothing based, allowing to
choose a
 > >> version over another.
 > >>
 > >
 > > 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.
 >

Here it was the confusion, since in my mind, I though we were going
line by
line. You said that in the first version we won't have this, but ideal
implementation it should 

Re: [xwiki-devs] [Proposal] Merge on save

[Eduard Moraru]

Also, there is the possibility of having to go though the conflict
resolution screen multiple times if, whenever trying to finish it and press
save, a new change was done in the background user, generating a conflict
with the version you have just resolved. If it's a very popular page that
users are constantly editing generally on the same places of the document,
this could get a bit annoying the more time you spend in edit mode :)

On Mon, May 27, 2019 at 5:25 PM Eduard Moraru  wrote:

> Hi,
>
> I feel we're over-engineering things a bit, at least for a fist version.
> My feeling is that the approach is to go with an UI-first version (the
> whole talk about being able to choose "mine" vs "their" versions) and only
> then, at a later point, coming back to a text-based version that allows you
> to fix the details. Why not go the other way around, in a simpler and
> already familiar (to some at least) yet flexible solution of starting with
> the text-based version, since we are editing wiki syntax after all?
>
> IMO, the easiest thing we could do is that, when a save is attempted, a
> merge should be attempted first. If no conflict occurs and the merge can be
> done automatically, the save should be done on the DB as well and the user
> should not perceive anything, thus not affecting his flow.
>
> Note: I hope we are all on the same page when I say that the merge
> conflict resolution should target/work on wiki syntax in the UI as well.
>
> If, however, conflicts do occur, the save does not go to the DB. Instead:
> * If it was a save&continue, the UI should inform the user (popup/bottom
> screen notification) that the save failed because of a conflict and offer
> the possibility to keep editing or resolve the conflict
> * If it was a save&view (or if the user clicked "resolve conflict" after a
> failed save&continue), the UI should reload the (wiki) editor with the
> entire merged content that will include the conflicts in a way that is (at
> least in the first implementation) similar to how git conflicts are
> displayed in a file, i.e. clearly marked in the content (where the conflict
> starts and ends), showing your version vs the version that is currently on
> the server (in the DB). Example (with html, but imagine wiki syntax here
> and we could use something better than "HEAD", etc.):
> https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png
>
> An improved version (iteration) of this could then be to use something
> like CodeMirror's "merge" addon (since we already use CodeMirror in the
> syntax highlighting application). It supports 2-way or 3-way display and
> live diff computation between the versions, synchronized scrollbars, and
> other neat stuff: https://codemirror.net/demo/merge.html We could decide
> if in "our" version we include the user's original version OR if we put
> directly the merged version (where the auto-merges are already applied) OR
> if we have a button under the user's original version to perform auto-merge
> on request, leaving just the remaining conflicts to be handled by the user.
> Finally, when save&view is pressed in this mode (note: probably we need to
> disable save&continue so that the "conflict resolution" action is "atomic",
> i.e. without leaving the content in an unfinished merge state), whatever
> the edited version is will overwrite the DB version of the document (i.e.
> force with whatever it contains).
>
> WDYT?
>
> Thanks,
> Eduard
>
> On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> On Thu, May 23, 2019 at 6:33 PM Simon Urli  wrote:
>>
>> >
>> >
>> > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
>> > > On Thu, May 23, 2019 at 12:10 PM Simon Urli 
>> > 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.
>> >
>>
>> Here it was the confusion, since in my mind, I though we were going line
>> by
>> line. You said that in the first version we won't have this, but ideal
>> implementation it should go like that (and even at the word / character
>> level for realtime-editing).
>>
>>
>> > >
>> > >
>> > >>
>> > >> 2. The

Re: [xwiki-devs] [Proposal] Merge on save

[Eduard Moraru]

Hi,

I feel we're over-engineering things a bit, at least for a fist version. My
feeling is that the approach is to go with an UI-first version (the whole
talk about being able to choose "mine" vs "their" versions) and only then,
at a later point, coming back to a text-based version that allows you to
fix the details. Why not go the other way around, in a simpler and already
familiar (to some at least) yet flexible solution of starting with the
text-based version, since we are editing wiki syntax after all?

IMO, the easiest thing we could do is that, when a save is attempted, a
merge should be attempted first. If no conflict occurs and the merge can be
done automatically, the save should be done on the DB as well and the user
should not perceive anything, thus not affecting his flow.

Note: I hope we are all on the same page when I say that the merge conflict
resolution should target/work on wiki syntax in the UI as well.

If, however, conflicts do occur, the save does not go to the DB. Instead:
* If it was a save&continue, the UI should inform the user (popup/bottom
screen notification) that the save failed because of a conflict and offer
the possibility to keep editing or resolve the conflict
* If it was a save&view (or if the user clicked "resolve conflict" after a
failed save&continue), the UI should reload the (wiki) editor with the
entire merged content that will include the conflicts in a way that is (at
least in the first implementation) similar to how git conflicts are
displayed in a file, i.e. clearly marked in the content (where the conflict
starts and ends), showing your version vs the version that is currently on
the server (in the DB). Example (with html, but imagine wiki syntax here
and we could use something better than "HEAD", etc.):
https://d33v4339jhl8k0.cloudfront.net/docs/assets/55c3b5cae4b01fdb81eb1259/images/569e7be1c697914361560809/file-AzxXs4HkkG.png

An improved version (iteration) of this could then be to use something like
CodeMirror's "merge" addon (since we already use CodeMirror in the syntax
highlighting application). It supports 2-way or 3-way display and live diff
computation between the versions, synchronized scrollbars, and other neat
stuff: https://codemirror.net/demo/merge.html We could decide if in "our"
version we include the user's original version OR if we put directly the
merged version (where the auto-merges are already applied) OR if we have a
button under the user's original version to perform auto-merge on request,
leaving just the remaining conflicts to be handled by the user. Finally,
when save&view is pressed in this mode (note: probably we need to disable
save&continue so that the "conflict resolution" action is "atomic", i.e.
without leaving the content in an unfinished merge state), whatever the
edited version is will overwrite the DB version of the document (i.e. force
with whatever it contains).

WDYT?

Thanks,
Eduard

On Fri, May 24, 2019 at 2:53 PM Ecaterina Moraru (Valica) 
wrote:

> On Thu, May 23, 2019 at 6:33 PM Simon Urli  wrote:
>
> >
> >
> > On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
> > > On Thu, May 23, 2019 at 12:10 PM Simon Urli 
> > 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.
> >
>
> Here it was the confusion, since in my mind, I though we were going line by
> line. You said that in the first version we won't have this, but ideal
> implementation it should go like that (and even at the word / character
> level for realtime-editing).
>
>
> > >
> > >
> > >>
> > >> 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?
> >
>
> We should add a new configuration only if it's needed. Again, I think we
> are introducing a lot of things (parent/child relation, accessibility
> options, etc.) that we never test. We don't reach a conclusion by

Re: [xwiki-devs] [Proposal] Merge on save

[Ecaterina Moraru (Valica)]

On Thu, May 23, 2019 at 6:33 PM Simon Urli  wrote:

>
>
> On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
> > On Thu, May 23, 2019 at 12:10 PM Simon Urli 
> 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.
>

Here it was the confusion, since in my mind, I though we were going line by
line. You said that in the first version we won't have this, but ideal
implementation it should go like that (and even at the word / character
level for realtime-editing).


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

We should add a new configuration only if it's needed. Again, I think we
are introducing a lot of things (parent/child relation, accessibility
options, etc.) that we never test. We don't reach a conclusion by
ourselves, so trying to make everyone happy, we are just increasing the
complexity of selection for the user and for the testers.


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

The magnitude I had in mind applied for the line by line case. If you look
at the image
https://design.xwiki.org/xwiki/bin/download/Proposal/EditConflict/linescolor.png
, 3 lines were successfully merged, while having conflict on 1 line. So we
were tacking about different things.


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

The idea was to redirect the user as soon as possible in the View mode,
just display the bottom page notification a bit longer (or add a
notification display for the View step).

Thanks,
Caty


>
> 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  wrote:
> 
> 
> 
>  On 23/05/2019 09:31, Vincent Massol wrote:
> >> On 23 May 2019, at 09:25, Simon Urli  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 th

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

Hi everyone,

I'm coming back on this proposal since there was some ambiguities.

On 23/05/2019 11:10, Simon Urli 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.


So to be perfectly clear, the way I see the merge conflict window 
options in a first version would be with just 2 options:


  - Merge and solve conflicts with current user version
  - Merge and solve conflicts with previous user version

So it would be always a merge, a choice would be done *only* for the 
conflicts.
If I understood well, Thomas suggested on the chat that we would need 
two more options:

  - Save my version without merging
  - Loose my changes and reload previous version

I don't really agree since for me we want to always merge: in case you 
don't have a conflict, you don't have the capability to choose between 
previous version and yours, so IMO it doesn't make really sense to 
propose those options in case of conflict only.
Now this might be related to point 2, since with an user option to 
always display the save conflict window (even in case there's no merge 
conflict), those option would make sense.


I think we need a vote for this.


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 think we need a vote for this option too.

Thanks,
Simon


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



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

On 23 May 2019, at 09:25, Simon Urli  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 
coul

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

> On 23 May 2019, at 17:59, Simon Urli  wrote:
> 
> 
> 
> On 23/05/2019 17:51, Vincent Massol wrote:
>>> On 23 May 2019, at 17:47, Simon Urli  wrote:
>>> 
>>> 
>>> 
>>> On 23/05/2019 17:37, Vincent Massol wrote:
> On 23 May 2019, at 17:33, Simon Urli  wrote:
> 
> 
> 
> On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
>> On Thu, May 23, 2019 at 12:10 PM Simon Urli  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.
>>> 
>>> First I'm not sure the presence of the poll would be enough: you can 
>>> imagine that the poll would be done just before the user clicks on save so 
>>> he won't see it.
>>> And more importantly as I mentionned the poll won't be done immediately. We 
>>> might have it in another release. So I'd prefer if we have a backup plan.
>> ok makes sense. I’m asking because your plan didn’t mention the different 
>> steps and what you propose to do when and you dropped this polling idea from 
>> your list of items :)
> 
> It was point 4 of https://markmail.org/message/wkot52soi6vnabvo

ok my bad then. I missed it or misunderstood it for something else.

Thanks
-Vincent

>> Thanks
>> -Vincent
 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  wrote:
> 
> 
> 
> On 23/05/2019 09:31, Vincent Massol wrote:
>>> On 23 May 2019, at 09:25, Simon Urli  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 ca

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

On 23/05/2019 17:51, Vincent Massol wrote:




On 23 May 2019, at 17:47, Simon Urli  wrote:



On 23/05/2019 17:37, Vincent Massol wrote:

On 23 May 2019, at 17:33, Simon Urli  wrote:



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

On Thu, May 23, 2019 at 12:10 PM Simon Urli  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.


First I'm not sure the presence of the poll would be enough: you can imagine 
that the poll would be done just before the user clicks on save so he won't see 
it.
And more importantly as I mentionned the poll won't be done immediately. We 
might have it in another release. So I'd prefer if we have a backup plan.


ok makes sense. I’m asking because your plan didn’t mention the different steps 
and what you propose to do when and you dropped this polling idea from your 
list of items :)


It was point 4 of https://markmail.org/message/wkot52soi6vnabvo


Thanks
-Vincent



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



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

On 23 May 2019, at 09:25, Simon Urli  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 t

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

> On 23 May 2019, at 17:47, Simon Urli  wrote:
> 
> 
> 
> On 23/05/2019 17:37, Vincent Massol wrote:
>>> On 23 May 2019, at 17:33, Simon Urli  wrote:
>>> 
>>> 
>>> 
>>> On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
 On Thu, May 23, 2019 at 12:10 PM Simon Urli  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.
> 
> First I'm not sure the presence of the poll would be enough: you can imagine 
> that the poll would be done just before the user clicks on save so he won't 
> see it.
> And more importantly as I mentionned the poll won't be done immediately. We 
> might have it in another release. So I'd prefer if we have a backup plan.

ok makes sense. I’m asking because your plan didn’t mention the different steps 
and what you propose to do when and you dropped this polling idea from your 
list of items :)

Thanks
-Vincent


>> 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  wrote:
>>> 
>>> 
>>> 
>>> On 23/05/2019 09:31, Vincent Massol wrote:
> On 23 May 2019, at 09:25, Simon Urli  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 sectio

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

On 23/05/2019 17:37, Vincent Massol wrote:




On 23 May 2019, at 17:33, Simon Urli  wrote:



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

On Thu, May 23, 2019 at 12:10 PM Simon Urli  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.


First I'm not sure the presence of the poll would be enough: you can 
imagine that the poll would be done just before the user clicks on save 
so he won't see it.
And more importantly as I mentionned the poll won't be done immediately. 
We might have it in another release. So I'd prefer if we have a backup 
plan.


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



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

On 23 May 2019, at 09:25, Simon Urli  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 sho

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

> On 23 May 2019, at 17:33, Simon Urli  wrote:
> 
> 
> 
> On 23/05/2019 16:00, Ecaterina Moraru (Valica) wrote:
>> On Thu, May 23, 2019 at 12:10 PM Simon Urli  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  wrote:
> 
> 
> 
> On 23/05/2019 09:31, Vincent Massol wrote:
>>> On 23 May 2019, at 09:25, Simon Urli  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 cho

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

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

On Thu, May 23, 2019 at 12:10 PM Simon Urli  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  wrote:



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

On 23 May 2019, at 09:25, Simon Urli  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 compl

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

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




On 23 May 2019, at 11:37, Thomas Mortagne  wrote:

On Thu, May 23, 2019 at 11:10 AM Simon Urli  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  wrote:



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

On 23 May 2019, at 09:25, Simon Urli  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

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

> On 23 May 2019, at 16:00, Ecaterina Moraru (Valica)  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]

Re: [xwiki-devs] [Proposal] Merge on save

[Ecaterina Moraru (Valica)]

On Thu, May 23, 2019 at 12:10 PM Simon Urli  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  wrote:
> >>
> >>
> >>
> >> On 23/05/2019 09:31, Vincent Massol wrote:
>  On 23 May 2019, at 09:25, Simon Urli  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
> 

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

> On 23 May 2019, at 11:37, Thomas Mortagne  wrote:
> 
> On Thu, May 23, 2019 at 11:10 AM Simon Urli  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  wrote:
 
 
 
 On 23/05/2019 09:31, Vincent Massol wrote:
>> On 23 May 2019, at 09:25, Simon Urli  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

Re: [xwiki-devs] [Proposal] Merge on save

[Thomas Mortagne]

On Thu, May 23, 2019 at 11:10 AM Simon Urli  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  wrote:
> >>
> >>
> >>
> >> On 23/05/2019 09:31, Vincent Massol wrote:
>  On 23 May 2019, at 09:25, Simon Urli  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

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

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



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

On 23 May 2019, at 09:25, Simon Urli  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 

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

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

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

> On 23 May 2019, at 09:43, Simon Urli  wrote:
> 
> 
> 
> On 23/05/2019 09:31, Vincent Massol wrote:
>>> On 23 May 2019, at 09:25, Simon Urli  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  wrote:
> Hi Simon,
> 
>> On 22 May 2019, at 10:45, Simon Urli  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.
>> 
>>>

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

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

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

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




On 23 May 2019, at 09:25, Simon Urli  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  wrote:

Hi Simon,


On 22 May 2019, at 10:45, Simon Urli  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
f

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

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

Hi Simon,


On 23 May 2019, at 09:14, Simon Urli  wrote:

Hi Vincent, all,

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

Hi Simon,

On 22 May 2019, at 10:45, Simon Urli  wrote:

Hi everyone,

I'm working on the merge on save for the roadmap of 11.5 and I need some 
decision to be taken.

The main idea of the merge on save, is to try to merge users work in case of 
save conflict. Knowing that the merge might led to merge conflict in case of 
edits on the same places. Those merge conflict can be tackled automatically, 
but a priority will be then given to one version over another.

I first propose to add an option in user profile, so users would have the 
possibility to choose between:
  1. Always merge automatically the work, even in case of merge conflict

I don’t understand this part. If there’s a conflict it means it cannot be 
merged… So would it do? Take latest version and overwrite previous version?


We have an automatic fallback in case of conflict, for which we can choose the 
strategy: use current, previous or next version. By default the strategy is to 
take the current version.
So the merge is never stucked in case of conflict, by default it returns the 
current version.


That’s really a bad idea IMO. By definition, a conflict is … a conflict… 
there’s no way to merge that automatically or it’s not a conflict…. If you do, 
then you have data loss. Which is not acceptable (it’s the worse thing that can 
happen and exactly what we’re trying to avoid with this feature! ;)). The user 
has to be presented the conflict and needs to be asked what he wants to loose: 
his data or the data from the last person who saved. And give him a solution to 
store his content so that he can merge it manually line by line later on (save 
his content on another special page, in memory (risky), etc).


I'm just stating about the current implementation of the document merge 
here. It's just how it works right now. And if you use the version the 
user is trying to save as the fallback strategy (which was what we 
discussed for option 1), you'd never get a data loss: all versions would 
be stored in revisions.


Now I agree with you that option 1 is not a good idea, as I said in my 
first mail I'm afraid that the user would feel the same as before the 
warning conflict window.


Simon


And in the next version, we’ll need to ask him this but line by line so that 
it’s not all or nothing.

Do you agree?

Thanks
-Vincent



Simon

  2. Always merge automatically, but ask what to do in case of merge conflict
  3. Always ask what to do in case of save conflict

Now the question is: what should be the default option?

Certainly not 1! 2 is really the best to me.
Thanks
-Vincent

Option 1 looks like a good fit for decreasing the number of clicks to do, but 
I'm a bit afraid that in case of conflict they would have the same feeling as 
before the warning conflict window: i.e. to loose some part of their work.

WDYT?

Simon

--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com


--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com




--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

> On 23 May 2019, at 09:25, Simon Urli  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  wrote:
>>> Hi Simon,
>>> 
 On 22 May 2019, at 10:45, Simon Urli  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
 
 --
 Si

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

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


Hi Simon,


On 22 May 2019, at 10:45, Simon Urli  wrote:

Hi everyone,

I'm working on the merge on save for the roadmap of 11.5 and I need some

decision to be taken.


The main idea of the merge on save, is to try to merge users work in

case of save conflict. Knowing that the merge might led to merge conflict
in case of edits on the same places. Those merge conflict can be tackled
automatically, but a priority will be then given to one version over
another.


I first propose to add an option in user profile, so users would have

the possibility to choose between:

  1. Always merge automatically the work, even in case of merge conflict


I don’t understand this part. If there’s a conflict it means it cannot be
merged… So would it do? Take latest version and overwrite previous version?


  2. Always merge automatically, but ask what to do in case of merge

conflict

  3. Always ask what to do in case of save conflict

Now the question is: what should be the default option?


Certainly not 1! 2 is really the best to me.

Thanks
-Vincent


Option 1 looks like a good fit for decreasing the number of clicks to

do, but I'm a bit afraid that in case of conflict they would have the same
feeling as before the warning conflict window: i.e. to loose some part of
their work.


WDYT?

Simon

--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com





--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

Hi Simon,

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

Re: [xwiki-devs] [Proposal] Merge on save

[Simon Urli]

Hi Vincent, all,

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

Hi Simon,


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




--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com

Re: [xwiki-devs] [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  wrote:

> Hi Simon,
>
> > On 22 May 2019, at 10:45, Simon Urli  wrote:
> >
> > Hi everyone,
> >
> > I'm working on the merge on save for the roadmap of 11.5 and I need some
> decision to be taken.
> >
> > The main idea of the merge on save, is to try to merge users work in
> case of save conflict. Knowing that the merge might led to merge conflict
> in case of edits on the same places. Those merge conflict can be tackled
> automatically, but a priority will be then given to one version over
> another.
> >
> > I first propose to add an option in user profile, so users would have
> the possibility to choose between:
> >  1. Always merge automatically the work, even in case of merge conflict
>
> I don’t understand this part. If there’s a conflict it means it cannot be
> merged… So would it do? Take latest version and overwrite previous version?
>
> >  2. Always merge automatically, but ask what to do in case of merge
> conflict
> >  3. Always ask what to do in case of save conflict
> >
> > Now the question is: what should be the default option?
>
> Certainly not 1! 2 is really the best to me.
>
> Thanks
> -Vincent
>
> > Option 1 looks like a good fit for decreasing the number of clicks to
> do, but I'm a bit afraid that in case of conflict they would have the same
> feeling as before the warning conflict window: i.e. to loose some part of
> their work.
> >
> > WDYT?
> >
> > Simon
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > simon.u...@xwiki.com
> > More about us at http://www.xwiki.com
>
>

Re: [xwiki-devs] [Proposal] Merge on save

[Vincent Massol]

Hi Simon,

> On 22 May 2019, at 10:45, Simon Urli  wrote:
> 
> Hi everyone,
> 
> I'm working on the merge on save for the roadmap of 11.5 and I need some 
> decision to be taken.
> 
> The main idea of the merge on save, is to try to merge users work in case of 
> save conflict. Knowing that the merge might led to merge conflict in case of 
> edits on the same places. Those merge conflict can be tackled automatically, 
> but a priority will be then given to one version over another.
> 
> I first propose to add an option in user profile, so users would have the 
> possibility to choose between:
>  1. Always merge automatically the work, even in case of merge conflict

I don’t understand this part. If there’s a conflict it means it cannot be 
merged… So would it do? Take latest version and overwrite previous version?

>  2. Always merge automatically, but ask what to do in case of merge conflict
>  3. Always ask what to do in case of save conflict
> 
> Now the question is: what should be the default option?

Certainly not 1! 2 is really the best to me.

Thanks
-Vincent

> Option 1 looks like a good fit for decreasing the number of clicks to do, but 
> I'm a bit afraid that in case of conflict they would have the same feeling as 
> before the warning conflict window: i.e. to loose some part of their work.
> 
> WDYT?
> 
> Simon
> 
> -- 
> Simon Urli
> Software Engineer at XWiki SAS
> simon.u...@xwiki.com
> More about us at http://www.xwiki.com