On Tue, Dec 11, 2012 at 10:26 AM, Pavel Sanda <sa...@lyx.org> wrote: > We currently use integrated SVN support of LyX for this. > The merge conflicts are avoided by locking the whole document or childern > (parts of the text).
It is precisely because locking doesn't scale that we have branching and merging. Locking simply does not scale. This is true even of documents (as opposed to source code). > While we are at possible LyX support of git, can you explicitly name the > commands used for your workflow? Like any team workflow: - each team member must be able to work on their changes independent of the rest of the team, even when the changes overlap This requires support for merging. I've been thinking about this a fair bit and I think there's a number of possible strategies to computing a 3-way diff suitable for merging with manual conflict resolution. Here's my stab at low-disruption (to LyX source, that is) strategy: 1. export each of the two or three LyX document versions as XML, using a schema that is as direct a representation of LyX document structure as possible 2. apply an XSL to change the schema to a document structure that is deeper (nested sections, ...) 3. apply an XML diff algorithm that looks for additions/deletions of nodes, node *moves*, and node changes 4. apply an automatic merge algorithm to the base version using the diffs from (3) 5. apply an XSL to flatten the document structure 6. convert the result back to .lyx format 7. present the result to the user for manual conflict resolution Of these the only difficult (magical) step is (4), and that's probably only because I've not researched it well enough. > I'm also interested for criteria for commit/push/merge/pull (e.g. do you push > immediatelly after commit?) I have several different workflows. The most common one is to create a branch as a copy of master, do a bunch of work there, then pull and update master, rebase my branch, repeat until done, then send a pull request. Another workflow is to maintain a branch that is a merger of several feature branches, which I use until all those feature branches are merged upstream. > To me, git concepts are unnecessarily complicated and tools like GNU RCS or > SVN are better suited for document tracking. I've used a large number of VCSes (Teamware, CVS, SVN, Clearcase, PRCS, fossil, git, and others), and I find none as powerful or awesome as git. I understand why many find git hard to understand, but I don't think this is as much git's fault as it is that distributed, lock-less version control is inherently hard, but also the only game in town (see above comment about locking not scaling). Nico --
