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 

[xwiki-devs] [ANN] XWiki 11.4 released

[Ecaterina Moraru (Valica)]

The XWiki development team is proud to announce the availability of XWiki
11.4.
This release brings improvements to the management of the conflicts
encountered when editing a page. We've also provided better explained error
messages for several cases, in order for the users to understand more
easily the occurring issues. For developers we've added the ability to
write a wiki macro in velocity and make its content inline-editable.

You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download

Make sure to review the release notes:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.4/

Thanks for your support
-The XWiki dev team

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] Map Application - GSoC 19

[Ecaterina Moraru (Valica)]

On Fri, May 24, 2019 at 9:19 PM Fawad Ali  wrote:

> Should I create jira issues for any updates I do during development? I made
> my commits like INTMAP-R for each revision I did. For simple
> commits like changing the Progress.md file or a line or two in pom.xml, do
> I use "[Misc]" for identifying the commit?
>

All the code commits need to be associated with an issue. The reason is
also practical: when you look at the blame, you will easily identify the
issue, and the issue will list screenshots, multiple commits, related
issues, etc.

Keep [misc] just for edge cases or exceptions, but the Progress.md is not
code, so you don't need an issue for that. Still, it's a bit strange to
have the progress in gitHub, since it's more project management, than code.
When you will release the application, that page will able be part of the
release. Alternatively, you could keep the progress in a design page, but
it's also up to you.


>
> 8.4-6 is the default version on
>
> https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/CreatingExtensions/#HBuildingaXARwithMaven
> so
> I did not change that. It is changed to 11.1 after the fix with encoding
> issues. Thanks for that.
>

On the community side, we support just 3 version (see
https://www.xwiki.org/xwiki/bin/view/Main/Support#HSupportedVersions). So
in practice, new applications should support at least the LTS. Our current
LTS is 10.11.8 (so 10.11.x). The 8.x version in .pom was just an example.
You should also try to see if you have the same encoding issues with
10.11.x versions, if not, use that as a parent.


>
> I was using the snapshots version to mark the completion of every major
> function. Mainly a simple map and a path map for now so the version 1.0.2.
> I would like to know if snapshots are supposed to be released.
>

"every major functions" will be tracked in issues, not in the project
version. We don't release snapshots versions. Snapshots builds are used
when continuous integration is enabled. More at
https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices#HReleaseCyclesandReleaseStrategy
. You project releases should start at 1.0, etc.


>
> For the URL path Map/Maps do you have a better path in mind for the created
> maps? I think its right when all the other paths are hidden for the user.
>

the URL should be as short as possible for the end-user and semantic. If
you have 'Map' in the breadcrumb, the user will go in each parent to see
functionality.


> I will be sure to provide screenshots for the next time. :)
>

Easier to review and to get traction. Thanks :)


>
> For combining all the maps in a single livetable, I have a perspective that
> for this application, every map is of a "kind" like a "path map" or "simple
> map" or later on "filtered list map". So I separated the maps based on that
> perspective. WDYT? Should I treat all the maps same?
>

We need Stephane 's opinion since he was the one that proposed the project,
so he knows better the use cases.


> Thankfully, the Map Macro uses the Macros.MapMacro space so we are safe for
> that.
>
> For the creation options, should I create a single template for the "Add"
> button and separate the map editors with tabs? If I create a template for
> each kind of map, the templates will become bulky I think.
>

You could select the type of map you want from a checkbox in the create
sheet. I would unify as much as possible the way to create maps.


>
> I also wanted to talk about filtered list maps so that I can move on with
> the development. Stephane sent me a link in the talks we had prior to this.
>
> https://napoleon-sainte-helene.plan-interactif.com/en/#!/category/886826/@-15.967188036753065,-5.710573196411134,13
>
> What kind of options do you have in mind for the filterable list? A general
> flow would really help me in direction.
>

Stephane?


>
> Thanks. :)
>

Thanks,
Caty

>
> Best,
> Fawad
>
>
> On Fri, May 24, 2019 at 10:02 PM Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
> > Some notes:
> >
> > - Please create issues in JIRA and commit over the issues,
> >
> >
> https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HRule:AlwaysputaJIRAissuereferenceincommitmessages
> >
> > - Why did you chose the 8.4-6 parent?
> >
> > - pom version should not be 1.0.2-SNAPSHOT , since you didn't had any
> > previous release
> >
> > - I don't have the errors you've pasted when doing mvn xar:format. For me
> > it adds only a single space. What OS are you using? Maybe try to clean
> your
> > environment? Not really sure what to suggest, especially since enygma
> > didn't reproduce the problem either.
> >
> > - It's a bit strange the Map/Maps URL path.
> > - Currently it works nicely. Would have been easier to provide some
> > screenshots in order to make people want to test the app :)
> >
> > - in terms of UX, we will need to combine:
> > -- all the maps in a single livetable,
> > -- under the same 'Map' space (careful - please test the Map