An alternative would be to support an RCS format where everything is explicitly saved forever, so e.g. you not only know when the document
You mean that kind of stuff when you sent out a contract proposal as .lyx file and the recipient is able to read all earlier versions when he looks on the file with a text viewer?
I'd rather that the recipient could do this from within the GUI. My co-authors probably wouldn't find it any easier to dig around in text than just compare the different versions with eyeballs.
I like this idea. This reminds me pretty much of the only reason why I like receiving .doc files...
If I explicitly choose to send you a file in RCS format chances are that I liked the idea too. It is always nice when both parties are happy. Sarcasm aside, I tend to avoid the risk of losing data over avoiding possible future privacy issues. I'd enable the RCS format for all my academic work. Also, as discussed below, the Word revision management has important features (such as merging two versions) that LyX is missing. On 3/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I find this contract example interesting from the point of view of version control. While composing your draft of the agreement, you probably want revision capabilities. Then you send the recipeient a file, and you *dont* want him to be able to see your old revisions.
In this case you probably want to send a the snapshot. If you use RCS this means sending the .lyx file instead of the ".lyx,v" file. In any case, LyX files aren't really suitable for transmission since they don't include child documents or included graphics. A "collect for output" function would be useful. Is one planned? Would such a converter, perhaps written in python, be a welcome addition to the project?
The recipient will then revise the file, and he would possibly appreciate revision capabilities while doing this - perhaps to compare his changes to the original version.
It should be feasible to parse the output of diff and convert it to a Change Tracking enabled .lyx file. Any interest in such a converter?
Then when sending it back to you, the recipient doesn't want *you* to be able to see his internal revisions. And finally, you probably would like to use revision capabilities to see what the recipient changed compared to the version that you sent him...
All supported by parsing diff files. If want wanted to be able to merge the changes from forked files (rather than just consider one to be "old" and the other to be "new") you'd need to be able to tell when the fork occurred. We could attempt to guess this by finding which version in our own version control has the smallest diff with the new file. A reasonably robust way would be to add a randomly generated token to the .lyx file for each change. So e.g. if we have saved the file 3 times we may have a tokens "4e9fab,gh9Zb2,Fe9gfA" line in the lyx file. If we recieve a .lyx file we successively remove tokens from the end until we have a file in our version control with that exact token string. We then apply the diff to the latest version in our version control to get a file the contains all changes we have access to. Two privacy concerns: - this would allow the recipient to infer how many times this document has been saved. - this would allow our Random Number Generator to leak information to the recipient. In normal circumstance this information should not commercially sensitive.
How well would change tracking deal with this today? Aren't changes stored inside the LyX file?
It would be trivial to convert a lyx file with change tracking to a diff. This is perhaps the easiest solution, however LyX does not support CT for settings etc. yet. -- John C. McCabe-Dansted PhD Student University of Western Australia
