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