On Wed, May 08, 2013 at 12:52:17PM +0200, Stephan Beal wrote: > On Wed, May 8, 2013 at 12:28 PM, Lluís Batlle i Rossell > <[email protected]>wrote: > > > One thing is not be able to merge; the other is losing information > > silently. > > Very annoying. > > > > It's not lost, per se, but it is (annoyingly) hidden in that case. The main > www UI doesn't (AFAIR) offer any features for browsing specific versions of > a page, and offers no diff for wiki pages, so it is not straightforward to > go find the "lost" data. So yes, it's "effectively" lost, but not "really" > lost. > > (just thinking out loud...) > i'm not quite sure we even _could_ sanely manage merge conflicts because > wiki pages are committed directly without the benefit of a fork-check via > autosync, which means that two people could commit pages on their repo > copies and a merge problem could not be detected until the sync with the > main repo. We would have no choice but to force a fork in that case (and to > somehow decide which one gets forked, or fork all of them). > > i'm sure nobody would object to someone expanding the wiki bits to take > part in the tag/branch/merge mechanisms. :)
In fact, I don't see why most VCS tend (somehow propose) to *not commit* merge conflicts before solving the conflicts. That makes the conflict solution 'disappear' from the timeline. I think it's fine in committing the conflict marks, and then the solution be an explicit extra checkin. The wiki and tickets could work that way. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
