On 7 Dec 2012, at 17:46, Nico Williams wrote: > On Fri, Dec 7, 2012 at 6:02 AM, Rainer M Krug <r.m.k...@gmail.com> wrote: >> On 07/12/12 12:45, Gregory Jefferis wrote: >>> Has anyone tried using latexdiff for change comparison in not merging? >>> Presumably a small script to export both versions to latex, invoke >>> latexdiff and then generate the marked-up PDF (which is what you get with >>> latexdiff) would work. For latexdiff there are already scripts to handle >>> git revisions which should allow one to diff a pair of arbitrary revisions >>> in a git repository. >> >> This should work, but it would be really nice if these changes were on LyX >> level and that one could >> save a file LyX file containing the differences as tracked changes. > > Right, the goal is to merge LyX documents. Unless converstion to/from > LaTeX is loss-less this is not a solution.
Just to clarify (since it was apparently not clear) my suggestion re latexdiff was specifically about change *comparison* not merging (though I had admittedly wondered about the possibility of a round trip via latex). But for me seeing changes in context is half the battle! Returning to the original question of merging + VCS, we currently use git + lyx for collaborative editing of papers in the lab (normally <=3 people) using git's built in merge. For us this a tremendous improvement over the emailed word file strategy. We have not managed to break a LyX file with an inappropriate automated merge. Merge conflicts are obviously possible if 2 users edit the same piece of text but in our use very rare – we encourage frequent push/pull, avoid e.g. fixing spelling errors all across the document without checking that changes have been committed and pushed. But on the rare occasions when conflicts do happen they unfortunately a showstopper for most users. It would indeed be very nice to have the option to merge in LyX when this happens, when one would typically use git mergetool. However, I do note that when a merge conflict happens, the file with conflicts left marked by git's regular merge or what you typically get by using git mergetool to start a generic merge tool (I use FileMerge on a Mac) is 3 way with ancestry. That means you only have to worry about the *conflicts* not the compatible changes in each branch. So in these circumstances firing up a text editor to fix the conflict might be much quicker (albeit more dangerous) than using LyX to accept/reject all changes displayed in a 2 way diff. In some sense a strategy that turned conflict markers into LyX tracked changes (or a 3 way diff) is really what one is after. When I am working with less tech savvy people outside the lab, I usually tell them to use track changes (and commit their work manually to git). You can even consider asking people to use track changes when using a VCS if someone is going to review all changes for integration. Regrettably there is still the possibility of merge conflict even after the discussion/fix noted here: http://www.lyx.org/trac/ticket/6058 if two or more people both start tracking changes before merging to master. Hope some of this experience might be of use. Best, Greg.
