+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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
