I have avoided parts of the issue first described in this discussion by introducing symbolic links mirroring any system involved. The situation is, however, slightly different in that I sync or transfer also the BibDesk file among systems first. When I then open the bib-file with BibDesk on any of the involved systems, the symbolic links ensure that the identical path exists as well. E.g. two systems with two users ‘userx’ and ‘usery’ having both a different location where the pdf repository resides:
/Users/userx/Documents/DataBases/PDFsOfRefs /Users/usery/MyProject/Literature/BibDesk/pdfRepository and having on each of those systems symbolic links such that on both systems exist both paths. This trick avoids losing the linked files and BibDesk does since years honor such a change of systems without a glitch. No need to go for local file field and the 1 to n relationship can be maintained the usual very powerful and convenient manner as BD offers. Regards, Andreas ETH Zurich Prof. em. Dr. Andreas Fischlin Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics CHN E 21.1 Universitaetstrasse 16 8092 Zurich SWITZERLAND andreas.fisch...@env.ethz.ch<mailto:andreas.fisch...@env.ethz.ch> www.sysecol.ethz.ch<http://www.sysecol.ethz.ch> +41 44 633-6090 phone +41 44 633-1136 fax +41 79 595-4050 mobile Make it as simple as possible, but distrust it! ________________________________________________________________________ On 19 Nov 2015, at 11:44, Christiaan Hofman <cmhof...@gmail.com<mailto:cmhof...@gmail.com>> wrote: On Nov 13, 2015, at 23:23, Christiaan Hofman <cmhof...@gmail.com<mailto:cmhof...@gmail.com>> wrote: On Nov 13, 2015, at 20:52, Adam R. Maxwell <amaxw...@me.com<mailto:amaxw...@me.com>> wrote: On Nov 13, 2015, at 04:05 , macula <ir...@me.com<mailto:ir...@me.com>> wrote: Regarding the huge diffs, I am fully in agreement with Michael. Autofile is a great feature, and so is the preview side panel, and it would be a pity to view this as an either/or proposition. The underlying code for files is pretty complicated, and some if it has been there since the editor window had a drawer where you could view a single attached PDF :). The fileview and alias code was a massive rewrite, and it's just not really compatible with the older attachment code. Maybe it could be changed at the serialization level to only save a path, but reading it would then be tricky… I just feel that the new BibDesk is somehow rubbing against the aesthetic and openness of the Bib(La)TeX format. I disagree with this; we namespace our private fields with a bdsk- prefix, to avoid clobbering anyone else's data. By comparison, I think BibLaTeX is not compatible with BibTeX as it's been defined for years (notably having changed the semantics of a field or two). This makes it impossible for BibDesk to support both. BibDesk's Date-Modified, Date-Added, Annote, Abstract are exceptions that predate our notion of private fields. Many if not all of us are scholars and share our materials with students and colleagues. Part of the appeal of this format is that its plain-text elegance and standardization liberate the data from any particular software. The very fact that BibDesk now presumes to "own" the database is a bit contrary to the philosophy of BibTeX, I think. To be clear, we "own" the bdsk-fields, and other well-behaved software should just ignore those. Sharing a .bib and set of attached files on a fileserver or cloud is an extremely complicated case, especially when multiple users can access it. Apple screws it up regularly, so I just prefer not to even try :). More practically, wouldn't this issue be solved if there was a scheme for storing the links locally in a separate file? I am thinking of a simple one-to-one index assigning each bibliographic entry (identified either by its BibTeX key or by a BibDesk-generate UUID) to a list of links to the entry's attachments? Two separate files would be a disaster with Finder copies and moving/renaming/sharing. I suppose one could store it in the resource fork or extended attributes, but that's a different ball of hurt. We considered doing this in a number of ways (a new data file format, a package-based format). The former died on the vine, and the latter makes it hard to get to the .bib file for TeX usage, and isn't really compatible with version control systems. For the time being, Michael, I am thinking to move my BibDesk-owned bib file out of the git repo and into dropbox, then use bibtool to produce a git-friendly version stripped of all links. You can probably do this with a template also, or use the minimal BibTeX export (but that might remove too much). I'm not entirely unsympathetic to the problems here, but they're not trivial to solve in a way that is robust, user-friendly, and backwards compatible. Adam Optionally leaving out the alias data would lead to somewhat fragile data, so the link could easily be lost. And it would make it very hard to move the database in your file system. It would certainly lead to data that is not backwards compatible, because currently the link is simply discarded when the alias data is missing. Also, using a full path instead of the alias would generally not solve anything because in general the directory structure on different file system will not match, so such a partial solution would be greatly reduced in value. So though I am also sympathetic to the problem, I am very much ambivalent to whether we should really try to solve this. Christiaan To test some of this out I have added a hidden (boolean) preference in the latest nightly build to only save the relative path of the linked files. It’s a boolean pref with key BDSKSaveLinkedFilesAsRelativePathOnly (see the Wiki on how to set this). Be careful though. The data will be much more fragile, and the saved data will not be compatible with older versions of BibDesk (i.e. before 1.6.4 (3701)). (When you’d open a file saved with this option in an older version of BD the linked files will be gone). For now this is just for testing purposes. I am not sure what to do with this, whether to advertise this on the Wiki, integrate this as an actual pref (that could be dangerous), or remove it later. Christiaan ------------------------------------------------------------------------------ _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net<mailto:Bibdesk-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
------------------------------------------------------------------------------
_______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
