Dear Christiaan and Adam, thanks for your responses! Both point into the direction that I can really start consolidating my master .bib file without worrying too much (after writing some backups, of course!) - so thank you for the positive answers as well!
<snip> >> - Citekeys issue: >> Some were generated manually in the old days when either I did not >> understand how to autogenerate them or the feature was not yet >> implemented. Others, I have autogenerated (using several different >> custom formats, stupid me). >> As I have used the keys in my .tex sources, these should not change >> (obviously). I just tried it, and BibDesk’s "Select duplicate" >> mechanism >> does find duplicate publications that have different citekeys. >> Great! I >> still have to clean those up manually anyway, and achieving a >> consistent >> scheme of cite keys would require reediting old .tex sources. Are >> there >> ways to do that automagically? If not, I’ll probably leave >> everything as >> is since it is rather a problem of cosmetics. > > Not everything, I couldn't even imagine how that may work. For example > BibDesk has no idea which .tex files you have and how referecnes are > used there, so you should not expect BibDesk to be able to fix > citations in those. Generating cite keys in BD is easy enough, as you > probably know. But synchronizing those with .tex files can be a pain, > and not something BD can do. > > The only thing I can think of is to write an AppleScript. It should > scan your .tex files for cite keys (in \cite and \bibitem), generate > new cite keys for those keys (which can also be called in > AppleScript), and replace them in the .tex files and in BD. I did not really expect BD to do that for me, my AppleScript ability is zero, so I'll just stick to what I have now, and work from there. I hope that I do not have many duplicates with different citekeys (will see!). >> - Autofile issues: >> Some of my bibs have papers filed (via Autofile, and some are also >> still >> stored somewhere on the file system of my PowerBook with links in the >> deprecated local-url field, but that is the minority of the files). >> Unfortunately, to different fixed locations on different computers. >> What >> is the best way to bring these together? > > I think the easiest way is to fix the .bib files at the local level > before merging and then moving the file together with the PDFs to your > joined location. <snip> Your solution makes perfect sense, I’ll definitely start this way. >> My ideal scenario would be to have a central repository on my >> university >> server that would sync with my workstations to provide offline >> access as >> well. That won’t work, so probably I’ll stick to mounting the >> university >> server (which is no problem from my work computer, but I need a VPN >> connection from home). >> What will happen if I change the "fixed location" to, say, >> "/Volumes/myserver/Papers/" -- can I, say, batch replace the location? > > There is a problem with moving papers to a different volume. BibDesk > can automatically follow linked files that are moved outside of > BibDesk. But when you "move" them to a different volume the files are > actually copied rather than moved, so BibDesk will not be able to find > the files in the new location. On the other hand if you use BibDesk > (in particular the manual auto-file feature) to move the files to the > new location, this should work. Just set the papers folder in the > prefs to "/Volumes/myserver/Papers/" and choose an appropriate > filename format, select the items or files you want to move there, and > choose an Auto-File menu item. Fine. I will try this. One small follow-up question to be sure: What’s going to happen if /Volumes/myserver/ is not mounted? Are the links still preserved if I re-save the file after some changes? A scenario likely to occur would be that I will keep the master.bib file in an SVN repository, travel to some library without wi-fi internet access with my PowerBook, discover some new books that I add to my working copy of master.bib, make some changes to particular pubs that already feature linked and autofiled files, save and commit my changes when I have internet access again. Would be great if all the links were intact afterwards. <snip> >> Probably the "match files" thing is the way to go, but actually I did >> never try this. > > It's meant to match unlinked files with files in your database. If you > have the files already linked somewhere it may not be what you want. Good to know! <snip> >> Thanks for an amazing app, and for all your comments! >> Stephan > > You're welcome, > Christiaan I repeat that and add that support both from the developer team and from the BD user community is always very quick, friendly, and helpful. Great to have this app, and the people behind it! As I believe it will be good to do everything in one session, I will start my consolidation in the next few days when I have more time, and of course, I’ll keep the list updated (well, especially if something goes wrong and I need help ;-)). I’ll document my steps for troubleshooting, and -- if that is needed -- also for the documentation. Best, Stephan ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
