One solution for the fear of large documents being sent for change tracking.
Generate a top level document that is nothing more than \include filenames of every piece of the document and offer a reference within the finished document which part of the overall document this section references. myCompleteDocument.lyx As a structure it would appear as a sort of meta document. If we wanted to worry about every little nuance why not just integrate Subversion as an optional Service with LyX and people could commit changes to documents and once verified they could fork that to a release update. -Marc J. Driftmeyer On Tuesday 20 April 2004 10:06, Ralph Boland wrote: > As a lyx user I am forever thankful (and forever expecting more) > for the work of lyx developers. > I read on the internet that lyx 1.4 supports change tracking. > > I will be glad to use this feature once lyx 1.4 is released > but I already want more. > > I am developing a parser generator tool and when I release it the > documentation will be in Lyx. > > I would like for users who find errors in the documentation > to be able to send me files pointing out these errors. > Change tracking will allow a way of doing this. > Users can simply send me a copy of the documentation containing > the proposed changes that they added using the change tracking facility. > > But a number of problems immediately come to mind. > > 1) I don't want users to send me a complete file > (say the size of the lyx user's guide) > just to point out a few minor mistakes. > They could instead send me a diff file > of the two verions of the documentations and I could then > reconstruct their verion of the documentation from from > my copy of the original lyx document and the diff file. > > This all sounds quite complicated. > Instead, lyx could have a command > "createLyxDiff" > which creates this diff file (say doc.lyx.diff) or (preferably) > some other file containing the necessary information. > The user then sends me the file doc.lyx.diff. I then run lyx > on my copy of the docuumentation and from lyx run the command > "installDiffFile: doc.lyx.diff" > which morphs my copy of the documention to > the users version containing his/her comments. > I then run the change tracking facility features to update the > documentation. > I think that this would be nice feature but it has problems of its > own. > > 2) If the above feature is implemented then there is a problem. > If two users send me change files to > update my documentation then once I update the documentation > based on one of the files, the other file will not match > correctly with the updated version of the document since > it was created based on the older original version of > the documentation. > Thus the "installDiffFile:" command needs > to be able to load multiple (possibly a large number) of > doc.lyx.diff.num files at one time and > the change tracking facility of lyx needs to support processing > them all at one time. > > With this feature when the document is released > it would have embedded in it a date stamp. > Once that date is reached copies of the document would not > allow change tracking to be used (with some kind of > override facility of course). > Also, once that date is reached I would run > lyx on the document and all the doc.lyx.diff.num files I have > received and update the documentation accordingly. > I would then release the new version of the documentation > with a new embedded date stamp. > > Note that this implies documentation releases, > much more often then say the sofware releases. > I believe this mechanism will result in much more rapid > development of user documentation. > It should result in documentation that is very clean in terms > of typos (but of course doesn't guaranttee quality documention). > Since the documentation for Lyx is in Lyx, the first > benifitiary of this feature could be Lyx itself. > > Comments welcome. > > Ralph Boland
