[xwiki-devs] Should we continue trying to merge single line content when upgrading a XAR extension ?
3 Jul
2014
3 Jul
'14
11:01 a.m.
Hi devs,
from time to time we get a proposed merge which is not very accurate
in a conflict for a single line field which can sometime be quite a
pain when that content is velocity like in document titles. Many users
just clic "continue" button without looking at the conflict and end up
with a bad title.
By default we pretty much have two choices for single line fields:
1/ continue trying to do a 3 ways merge
2/ do not do any 3 ways merge (or see it as a line based merge which
pretty much mean the same thing). Like at any level merge default on
current in case of conflict so the proposed merge for this field would
be to do nothing basically
WDYT ?
1/ support simple use case without displaying an annoying conflict UI
but it also means being almost sure to have bad title in more complex
use cases if you just click continue
I guess 2/ is a bit safer.
--
Thomas Mortagne
3 Jul
3 Jul
11:11 a.m.
Hi Thomas,
On 3 Jul 2014 at 11:02:42, Thomas Mortagne
(thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote:
Hi devs,
from time to time we get a proposed merge which is not very accurate
in a conflict for a single line field which can sometime be quite a
pain when that content is velocity like in document titles. Many users
just clic "continue" button without looking at the conflict and end up
with a bad title.
Actually what would help a lot is a preview of what you’d get with the selected conflict
options because otherwise the user to know the algorithm and compute it in his head by
checking the previous value, the changes done to the page and the new values and that’s
not easy at all.
By default we pretty much have two choices for single
line fields:
1/ continue trying to do a 3 ways merge
2/ do not do any 3 ways merge (or see it as a line based merge which
pretty much mean the same thing). Like at any level merge default on
current in case of conflict so the proposed merge for this field would
be to do nothing basically
WDYT ?
1/ support simple use case without displaying an annoying conflict UI
but it also means being almost sure to have bad title in more complex
use cases if you just click continue
I guess 2/ is a bit safer.
I prefer to be on the safe side with 2 (line-based merge), hoping that the user will not
have to resolve too many conflicts when upgrading…
It would be interesting to try out an upgrade, from some existing real life version (from
xwiki.org or myxwiki.org for ex) to a new XWiki version having 2/ implemented and see how
many more conflicts would be generated.
Thanks
-Vincent
11:16 a.m.
On Thu, Jul 3, 2014 at 11:11 AM, vincent(a)massol.net <vincent(a)massol.net> wrote:
--
Thomas Mortagne
Hi Thomas,
On 3 Jul 2014 at 11:02:42, Thomas Mortagne
(thomas.mortagne@xwiki.com(mailto:thomas.mortagne@xwiki.com)) wrote:
By default you get a diff between what you curently have and what you
will get if you click continue, I don't see how this require the user
"to know the algorithm and compute it in his head".
Hi devs,
from time to time we get a proposed merge which is not very accurate
in a conflict for a single line field which can sometime be quite a
pain when that content is velocity like in document titles. Many users
just clic "continue" button without looking at the conflict and end up
with a bad title.
Actually what would help a lot is a preview of what you’d get with the selected conflict
options because otherwise the user to know the algorithm and compute it in his head by
checking the previous value, the changes done to the page and the new values and that’s
not easy at all. By default we pretty much have two choices for
single line fields:
1/ continue trying to do a 3 ways merge
2/ do not do any 3 ways merge (or see it as a line based merge which
pretty much mean the same thing). Like at any level merge default on
current in case of conflict so the proposed merge for this field would
be to do nothing basically
WDYT ?
1/ support simple use case without displaying an annoying conflict UI
but it also means being almost sure to have bad title in more complex
use cases if you just click continue
I guess 2/ is a bit safer.
I prefer to be on the safe side with 2 (line-based merge), hoping that the user will not
have to resolve too many conflicts when upgrading…
It would be interesting to try out an upgrade, from some existing real life version (from
xwiki.org or myxwiki.org for ex) to a new XWiki version having 2/ implemented and see how
many more conflicts would be generated.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
4 Jul
4 Jul
10:57 a.m.
I like the idea 2.
2014-07-03 11:16 GMT+02:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
On Thu, Jul 3, 2014 at 11:11 AM, vincent(a)massol.net
<vincent(a)massol.net>
wrote:
selected
conflict options because otherwise the user to know the algorithm
and compute it in his head by checking the previous value, the changes done
to the page and the new values and that’s not easy at all.
By default you get a diff between what you curently have and what you
will get if you click continue, I don't see how this require the user
"to know the algorithm and compute it in his head".
the user
will not have to resolve too many conflicts when upgrading…
Hi Thomas,
On 3 Jul 2014 at 11:02:42, Thomas Mortagne (thomas.mortagne(a)xwiki.com
(mailto:thomas.mortagne@xwiki.com)) wrote:
Hi devs,
from time to time we get a proposed merge which is not very accurate
in a conflict for a single line field which can sometime be quite a
pain when that content is velocity like in document titles. Many users
just clic "continue" button without looking at the conflict and end up
with a bad title.
Actually what would help a lot is a preview of what you’d get with the By default we pretty much have two choices for
single line fields:
1/ continue trying to do a 3 ways merge
2/ do not do any 3 ways merge (or see it as a line based merge which
pretty much mean the same thing). Like at any level merge default on
current in case of conflict so the proposed merge for this field would
be to do nothing basically
WDYT ?
1/ support simple use case without displaying an annoying conflict UI
but it also means being almost sure to have bad title in more complex
use cases if you just click continue
I guess 2/ is a bit safer.
I prefer to be on the safe side with 2 (line-based merge), hoping that
It would be interesting to try out an upgrade, from some existing real
life
version (from xwiki.org or myxwiki.org for ex) to a new XWiki
version having 2/ implemented and see how many more conflicts would be
generated.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:19 p.m.
I've had bad merges with string properties, especially user's email and
group members.
I also have bad diffs (version compare) with list properties, where the
removal of one item was shown as removing characters from 3-4 adjacent
items, since the version diff just transforms the whole list into an
array of characters, which discards any separation between the items.
The diff algorithms should have more levels of diff, first by lines,
then by words, then by chars in those words.
Anyway, on this vote, +1 for 2. Simple one-line texts are supposed to be
self-contained, trying to merge 2 different versions will likely lead to
something wrong, be it velocity code, an email address, a name, or even
a proper sentence: merging words from two different sentences into one
is not how one makes a correct sentence.
On 07/03/2014 05:01 AM, Thomas Mortagne wrote:
Hi devs,
from time to time we get a proposed merge which is not very accurate
in a conflict for a single line field which can sometime be quite a
pain when that content is velocity like in document titles. Many users
just clic "continue" button without looking at the conflict and end up
with a bad title.
By default we pretty much have two choices for single line fields:
1/ continue trying to do a 3 ways merge
2/ do not do any 3 ways merge (or see it as a line based merge which
pretty much mean the same thing). Like at any level merge default on
current in case of conflict so the proposed merge for this field would
be to do nothing basically
WDYT ?
1/ support simple use case without displaying an annoying conflict UI
but it also means being almost sure to have bad title in more complex
use cases if you just click continue
I guess 2/ is a bit safer.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
7:46 p.m.
On Fri, Jul 4, 2014 at 7:19 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
I've had bad merges with string properties,
especially user's email and
group members.
I also have bad diffs (version compare) with list
properties, where the
removal of one item was shown as removing characters from 3-4 adjacent
items, since the version diff just transforms the whole list into an
array of characters, which discards any separation between the items.
The diff algorithms should have more levels of diff, first by lines,
then by words, then by chars in those words.
We are not talking about the diff displayer here, as you can see in
ListProperty the merge work with list and not strings.
Anyway, on this vote, +1 for 2. Simple one-line texts are supposed to be
self-contained, trying to merge 2 different versions will likely lead to
something wrong, be it velocity code, an email address, a name, or even
a proper sentence: merging words from two different sentences into one
is not how one makes a correct sentence.
On 07/03/2014 05:01 AM, Thomas Mortagne wrote:
--
Thomas Mortagne
Hi devs,
from time to time we get a proposed merge which is not very accurate
in a conflict for a single line field which can sometime be quite a
pain when that content is velocity like in document titles. Many users
just clic "continue" button without looking at the conflict and end up
with a bad title.
By default we pretty much have two choices for single line fields:
1/ continue trying to do a 3 ways merge
2/ do not do any 3 ways merge (or see it as a line based merge which
pretty much mean the same thing). Like at any level merge default on
current in case of conflict so the proposed merge for this field would
be to do nothing basically
WDYT ?
1/ support simple use case without displaying an annoying conflict UI
but it also means being almost sure to have bad title in more complex
use cases if you just click continue
I guess 2/ is a bit safer.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
21 Jul
21 Jul
4:17 p.m.
+1 for 2
On Fri, Jul 4, 2014 at 8:19 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
I've had bad merges with string properties,
especially user's email and
group members.
I also have bad diffs (version compare) with list properties, where the
removal of one item was shown as removing characters from 3-4 adjacent
items, since the version diff just transforms the whole list into an
array of characters, which discards any separation between the items.
The diff algorithms should have more levels of diff,
first by lines,
then by words, then by chars in those words.
It has two levels currently: line and char. Splitting by word is not
trivial in all languages (e.g. Arabic or Chinese). I found this last
time I checked http://nlp.stanford.edu/software/segmenter.shtml .
Thanks,
Marius
Anyway, on this vote, +1 for 2. Simple one-line texts are supposed to be
self-contained, trying to merge 2 different versions will likely lead to
something wrong, be it velocity code, an email address, a name, or even
a proper sentence: merging words from two different sentences into one
is not how one makes a correct sentence.
On 07/03/2014 05:01 AM, Thomas Mortagne wrote:
Hi devs,
from time to time we get a proposed merge which is not very accurate
in a conflict for a single line field which can sometime be quite a
pain when that content is velocity like in document titles. Many users
just clic "continue" button without looking at the conflict and end up
with a bad title.
By default we pretty much have two choices for single line fields:
1/ continue trying to do a 3 ways merge
2/ do not do any 3 ways merge (or see it as a line based merge which
pretty much mean the same thing). Like at any level merge default on
current in case of conflict so the proposed merge for this field would
be to do nothing basically
WDYT ?
1/ support simple use case without displaying an annoying conflict UI
but it also means being almost sure to have bad title in more complex
use cases if you just click continue
I guess 2/ is a bit safer.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3710
days inactive
3728
days old
6 comments
5 participants
participants (5)
-
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
vincent＠massol.net