> the first thing is whether you both agree on this summary :) > maybe Richard would like to change some points :)
They are basically 'facts' extracted from the debate. Of course Richard can correct me if I were wrong. > - i don't like the 'extract all embed' feature in concept1. if some chaotic > co-author on the other side embed files from different paths on filesystem > i will be _very_ annoyed by lyx disseminate these file on hundred and one > locations on my filesystem. we shouldn't allow this to happen. i dont see > this > listed in cons of concept 1, but i consider this far worse deficiency than > other points written. > not to kill the concept1 completely - it could may be done that we allow > only embed/unembed files on the same directory level or in subdirs. This has been debated. Using the second approach, because lyx has to work on the unbundled .lyx file, it is difficult to restore relative locations of extracted files. This is why Richard chose not to unbundle files to their original locations. Unbundling will be an export feature that writes a .lyx file and its extracted external files to a new subdirectory under the document directory. The current .lyx file is not changed. > - i'm bit confused by the concept2 description. > * where is saved filename.lyx. > in filename.lyxdir/ or outside of this dir in bundled mode? how is it with > addind/deleting new files? filename.lyx and filename.lyxdir will be in the same directory. Adding an external file will copy that file to, e.g., filename.lyxdir/figures. If compression is enabled, filename.lyx will have plain text filename.lyx and filename.lyxdir. Otherwise, the 'document' is filename.lyx and filename.lyxdir. > * does this bundling movement means my coauthor can't work reasonably with > the bundled files (its hard if they are renamed all structure lost etc.)? Yes. The original structure of external files are lost. It is of course possible to allow users to specify locations within this filename.lyxdir structure, but this means more troubles for users. > * if he changes some picture would it be easy to get this change back to > _my_ structure? if this is not somehow doable this format is not much useful > for cooperation. No. You are forced to use a prespecified strcuture. Once you turn to bundled mode, you can not get your structure back. This is the reversibility problem I was talking about. > - if i understand it correctly in both cases the filename is discarded. why? > isn't only filepath the problem? In the first case, an embedded file is either anonymous (file links are not saved), or with known original source, which can be relative or absolute. I chose to password-protect both filename and filepath because filenames alone are not enough to recover the original external file structure. > - was there some conclusion about filename extension? if there are going to > be > any tricks with copying or moving .lyx file itself i smell thousand and one > problems of rewrites, bad deletions on user side etc. i think that some .lyz > would be much more appropriate here. I am not quite sure about what you are talking here. In my approach, a file will be given a random name and copied to lyx temp directory. This temp name will be used just for this file and be saved in .lyx file. The embedded files are sorted before written to .lyx file so there will be no massive content change after simple editions. In Richard's approach, a file is copied to filename.lyxdir, possibly renamed to avoid filename conflict. > now from completely different angle, imagine such kind of workflow: > > 1. i have all my files for typesetting some book in one directory with > possible subdir structure for chapter/pictures/repository info like > .svn or .git. > 2. now i want to send it to my coauthor for revisions, new chapter, > whatsover. > so i pack this whole directory into one archive and send it to my coauthor. > 3. he unpacks it edit whatsover he likes. then he packs it again and send me. > 4. i unpack it and start to use it normaly. in this point i can easily forget > i ever used some packing. and first thing i would like to see is usually > what happened, so some "git diff" or even "git log" should be possible. This will be my way of doing things as well. > now imagine we require that all bundled/embedded files are in the same > directory > or in subdirs. > the BIG question for before all: can be such constraint demanded on user at > all? I certainly disagree, but Richard and JMarc said yes. They were talking about not allowing any out of tree file. I strongly object any unnecessary restriction on how users use external files. > if yes the implications would be clear: > - we can use this directory as filename.dir in concept2 (or add some > cherry-picking as in concept1) > - the whole pack/unpack process seems to be more clear (at leat to me:) In Richard's approach, you can not keep your original directory structure. In my approach, you do 'embed all files' and send a single .lyx file to your co-author. After he finishes edition, you 'extract all embedded files', examine the files and copy them back to your directory structure. Note that my first (reverted) approach was designed around the idea of 'in-place' unbundling. That is to say, you can directly unbundle the file sent back by your co-author and svn diff. The new approach means one more step, but is a lot safer. > imagine for example we rename the bundled file extension to some, > so from that moment we know only two states: > 1) projet_dir.lyz 2) project_dir/...content_of_lyz > - we can forget about the path/filename issues > - we can hold the dir structure > - in case we rename the bundled extension some another we can even My approach continue to use plain text for embedded files and has no trouble with external files, directory etc. > but maybe such kind of solution was already discussed, don't know; > just sharing what came up in my mind while reading the previous mail, > because in both solutions i have seen nigthmares mainly in the phase > of packing/unpacking. concept2 seems to 'solve' that by avoiding moving > the files back, which in fact means leting do the hard job to the user. I hope that you feel comfortable with my pack/unpack solution. From the very begining, my design was around reversibility so that I could recover my local external file structure. My previous implementation was convenient but may be unsafe. The current approach should work well. Cheers, Bo
