[xwiki-devs] Should we continue trying to merge single line content when upgrading a XAR extension ?
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
Hi Thomas, On 3 Jul 2014 at 11:02:42, Thomas Mortagne ([email protected](mailto:[email protected])) 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
On Thu, Jul 3, 2014 at 11:11 AM, [email protected] <[email protected]> wrote:
Hi Thomas,
On 3 Jul 2014 at 11:02:42, Thomas Mortagne ([email protected](mailto:[email protected])) 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 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".
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
I like the idea 2. 2014-07-03 11:16 GMT+02:00 Thomas Mortagne <[email protected]>:
On Thu, Jul 3, 2014 at 11:11 AM, [email protected] <[email protected]> wrote:
Hi Thomas,
On 3 Jul 2014 at 11:02:42, Thomas Mortagne ([email protected] (mailto:[email protected])) 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 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".
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Fri, Jul 4, 2014 at 7:19 PM, Sergiu Dumitriu <[email protected]> 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:
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 for 2 On Fri, Jul 4, 2014 at 8:19 PM, Sergiu Dumitriu <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
vincent＠massol.net