Thanks for this detailed reply, Adam. I just finished reconfiguring
everything along the lines I suggested earlier: a Dropbox-synced BibDesk
library that includes all the machine-readable links, then a script that
uses bibtool to produce a fat-free, git-friendly version of the library
for versioning and sharing.
I am not entirely convinced that storing the volatile Bdsk-File links
outside the bib database would be such a messy solution (it could be a
hash-based solution in preference files, for example), but it's easy for
one to request features and daydream about "solutions" when one doesn't
have to actually implement them. So I'll cease fire for now.
FWIW, I couldn't resist bringing this issue up when I noticed that my
git repo crossed the 120MB mark! This is for a 1850-item plaintext .bib
database that has been undergoing modest, incremental revisions in only
170 commits. At this rate by the end of my career I'd be banned from
github, I suppose.
Cheers.
>> On Nov 13, 2015, at 04:05 , macula <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
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bibdesk-users mailing list
> Bibdesk-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bibdesk-users
>
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the
> discussion below:
> http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370p7578383.html
>
> To unsubscribe from Bibdesk-URLs keep changing when I save on
> different machines, visit
> http://bibdesk-users.661331.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7578370&code=aXIyOTlAbWUuY29tfDc1NzgzNzB8LTEzNjE1MTc1MTA=
Yannis Rammos
—
Doctoral Candidate, New York University
ram...@nyu.edu
twitter.com/YannisRammos
--
View this message in context:
http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370p7578384.html
Sent from the bibdesk users mailing list archive at Nabble.com.
------------------------------------------------------------------------------
_______________________________________________
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
