On Mon, Aug 2, 2010 at 10:00 AM, thyrsus <[email protected]> wrote: > As someone who always considered the Leo file the "source" and the > derived files as "secondary", this is of great importance to me. > > RIght now, there are two ways of collaborating on a Leo file: > > * cross your fingers and hope no one else makes any changes between > when you retrieve it from the version control system and when you > submit back > * lock it (available with subversion and others), explicitly > preventing anyone else from making changes, until saving the changes > in the VCS unlocks it.
I think the ekr_leoPy.leo approach solves the problem best, because the .leo file is explicitly something that only I should be updating. > * provide a means to reconcile conflicts within an XML file in a > visually easy to understand format. I'm glad you mention this. There is an analogy with inc-lint. Just as with xml files, ast's (parse trees) can not be used in any convenient way to do diffs. It's hopeless because there is far too much extraneous detail. In contrast, incl-lint will diff symbol tables that contain only relevant info. In any case, ekr_leoPy.leo should eliminate the need for impossible-to-do diffs. If somebody else changes ekr_leoPy.leo, I'll have no hesitation about reverting the change. It's the simplest thing that could possibly work. In other words, the distinction between using bzr for sharing and for backup is remarkably useful. It just simplifies everything. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
