On Mon, May 13, 2013 at 11:04:23AM +0200, Stephan Beal wrote: > On Mon, May 13, 2013 at 10:55 AM, Lluís Batlle i Rossell > <[email protected]>wrote: > > > A simple operation (similar to edit, just with the merge conflicts) could > > allow > > merging multiple leaves. > > > > What do you think? > > > While i'm not at all against the idea of upgrading the wiki pages to > full-fledged content, i just want to point out that this feature would > affect more than the www GUI: the (fossil wiki commit) and > (/json/wiki/save) commands would also be affected by this, and would need > to be expanded to catch/reject/report merge conflicts. That would be > relatively easy for (wiki commit), where we can simply exit() on conflict, > but more work for /json/wiki/save, where the conflict has to be reported > back to the user along with the conflict-merged data. Such a "non-success" > case does not fit in with the current "100% success" _or_ "100% failure" > response model, and the error reporting mechanism does not allow one to > send a payload back to the client (in this case the conflicted content). So > i'd need to find a mechanism we could use to report such > "not-total-failures" which isn't too difficult for clients to work with.
No, I only mean that the wiki pages should report about *multiple leaves*. With the current artifacts, wiki pages include the 'Parent artifact id', so it should be already possible to report that. I don't mean that we block any user in any operation. Then, we only need an extra operation that could *merge*. Imagine that you click the "Merge leaves" link; it should offer a text input like with wiki edit, but with the conflicts inside. The artifact of the wiki page, then, could include multiple parent artifact id to mean a merge. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
