On Aug 3, 2011, at 10:05, Michael McNeil Forbes wrote:
> Hi,
>
> I am trying to maintain a shared database with collaborators. I keep
> a version controlled (mercurial) copy of my master.bib file in a
> Dropbox folder along with a directory with all my autofiled papers:
>
> .hg/...
> master.bib
> BibDesk/<papers here>
>
> I then clone this and edit my cloned master.bib, allowing my
> collaborators (who don't use mercurial) to edit the dropbox version.
> Periodically I commit there changes, my changes, and merge the two to
> keep them in sync.
>
> This is kind of working, but I am having a few irritations and would
> appreciate some suggestions on how to smooth the workflow.
>
> 1) In order for all of us to see the papers, I had to "File papers in
> fixed location" "~/Dropbox/bibtex/BibDesk/". Reading previous
> articles I thought that "File papers relative to each document" would
> work, but I could never get this to work on my collaborators machines
> (the papers were always missing "?" even though when I would autofile
> on their machine, they would go to the correct spot. Should this have
> worked? (In which case I could try to debug further).
>
This should work if you keep the .bib file and the papers together, and when
you move them you move them together. You don't seem to do that, as you move
and copy your .bib file and papers separately from each other. When you
move/copy/synchronize you must make sure that either the *relative* location of
the .bib file and papers remains the same (compared to when the .bib file was
saved), or the absolute location should remain the same. Note that something
like "~/Dropbox/bibtex/BibDesk/" is not a fixed location, because it will be a
different location for you and for your collaborators ("~" gets expanded).
So the conclusion is that if you want to share your database with
collaborators, you (and your collaborators) should save the papers always
relative to your .bib file, and when you move or copy the .bib file you have to
also copy the papers, and vice versa, such that their relative location remains
fixed. This should be true for every step, both for you and between you and
your collaborators.
> 2) Although things work now, each time I open master.bib and save it
> on my machine *all* the Bdesk-File fields change. This means that
> whenever I merge my changes with theirs, I see a different field in
> *every* record. This noise makes it very inconvenient to find out
> what has changed. It does not matter which version I keep (as long as
> the files were autofiled properly) as BibDesk is able to find the
> files through the absolute link (which must be encoded in the
> Bdesk-File string).
>
> Is there a way to turn this off so that only the relative path name?
> I know this has been discussed before, and having the links to the
> actual files has many benefits, but for this workflow it is a real
> pain. Perhaps there is some way of telling my vc software to ignore
> these lines, but then I might miss a few cases where the files were
> not properly autofiled (and hence not moved to the Dropbox folder).
>
You cannot change the way BibDesk saved linked files. You can decide to use
Local-Url fields instead of linked files in the old way, and turn off automatic
conversion to linked files in the Default Fields prefs. Your collaborators must
then also do that. But you will loose all support for linked files, including
auto filing (though you could simulate it through script hooks).
> In short, for this workflow I think having simply the filename text
> would be the best option.
>
> 3) In order for things to work properly, I have to make sure that all
> collaborators set their preferences so that the generated cite-key and
> autofile filenames are identical. It seems that these should be
> stored on a per database level (in or along with the master.bib file)
> rather than application level preferences. Is there a streamlined way
> of ensuring that all collaborators have the same preferences for the
> database? (Maybe some sort of partial .plist file I could include in
> the repository that could be read when editing this database?)
>
No.
> 4) In order to ensure that the autofile names are unique I would like
> to include either the Doi or Eprint fields, however, often only one of
> these is defined. Is there a way of specifying the autofile name so
> that these fields are conditionally included? I tried something like
> "%s{Doi}[%f{Doi}][%f{Eprint}]" but the nested variables do not expand.
> Any suggestions? The current behaviour would be fine if I could
> disable the incomplete info warning message and have autofile work
> automatically unless *both* fields are empty.
>
No, this is simply not supported, there are limits to the complexity we can
offer (and it's already very complex).
> Apart from these issues, this workflow is quite successful.
>
> Thanks for a very useful tool!
Christiaan
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Bibdesk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
