On Mon, 13 Apr 2009, Richard Heck wrote:

 Yes, that's a major drawback ! But the .zlyx could be used as an
 "export" file format to share with others, then one could just merge
 back the .lyx embedded into the .zlyx : I see this as a way one can
 use this feature, but some may want to use it otherwise (as everyone
 does when using OOo for example, reinsert the figure)

This is where things get messy. If you just want an export format, then that actually exists already, kind of. There's a script, lyxpak.py, in the development tree that will "pack" a LyX file and all its dependencies, wherever they may be, into a tar, I think. Then it can be shipped off, unpacked, etc. The difficulty is then in "updating". Obviously, you can unpack the tar yourself and do with it as you will. But, for security reasons, you do not really want LyX to be able automatically to unpack and write to arbitrary locations in your filesystem.

Aren't there options to 'tar' that can help with this, e.g. only allowing things to be written to somewhere inside a subdirectory.

As for the "updating", I don't think 'tar' will be enough... you could expand the .tar-file into a separate directory and then compare the directories and manually move the files that have changed _and_ that you want to use to replace your version of those files. Then I thought a bit more for a solution, but what I came up with really just ended up amounting to a version control system where you were emailing changes.

So why not go for a distributed version control system that supports sending changes (or all of it) as e-mail. This way you can get by without a server.

/Christian

--
Christian Ridderström                           Mobile: +46-70 687 39 44

Reply via email to