Bibdesk-URLs keep changing when I save on different machines

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bibdesk-URLs keep changing when I save on different machines

macula
I have two machines with exactly the same folder hierarchy. Even their respective drives have the same name, the only difference being the host name, which obviously needs to be unique in the LAN.

I sync the two instances of my database using git and GitHub. All bibliography reside in my Dropbox and, once again, the paths are identical on the two machines.

However, even the slightest change on a machine, and subsequent Save, sometimes (but not always?) changes every Bdesk-File-N link in my database.

Any reason why this is happening?

When I first created the database, and started using this workflow, each machine had a differently named disk drive. I was puzzled at first, but soon realized that this is the reason for the volatile file links. So I renamed the drives to a common name, and I was under the impression that I had solved the issue. Alas, not so.

Any ideas? I am very tired of having these huge git-diffs every time I change a single umlaut or something…

Many thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Christiaan Hofman

On Nov 12, 2015, at 0:04, macula <[hidden email]> wrote:

I have two machines with exactly the same folder hierarchy. Even their
respective drives have the same name, the only difference being the host
name, which obviously needs to be unique in the LAN.

I sync the two instances of my database using git and GitHub. All
bibliography reside in my Dropbox and, once again, the paths are identical
on the two machines.

However, even the slightest change on a machine, and subsequent Save,
sometimes (but not always?) changes every Bdesk-File-N link in my database.

Any reason why this is happening?

When I first created the database, and started using this workflow, each
machine had a differently named disk drive. I was puzzled at first, but soon
realized that this is the reason for the volatile file links. So I renamed
the drives to a common name, and I was under the impression that I had
solved the issue. Alas, not so.

Any ideas? I am very tired of having these huge git-diffs every time I
change a single umlaut or something…

Many thanks.



These links also contain alias information, which is unique to a file system, in addition to path information.

Christiaan


------------------------------------------------------------------------------

_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

macula

Thanks, Christiaan. Is it possible to revert to old-fashioned plaintext paths? Clearly, many of us work on more than one machine, with syncing via git, the cloud or some other process, and I'm sure I am not the only one who wishes there was a more ecological way to handle changes. Perhaps a workflow that hasn't occurred to me?

Cheers.

On Nov 12, 2015, at 0:04, macula [hidden email] wrote:

I have two machines with exactly the same folder hierarchy. Even their
respective drives have the same name, the only difference being the host
name, which obviously needs to be unique in the LAN.

I sync the two instances of my database using git and GitHub. All
bibliography reside in my Dropbox and, once again, the paths are identical
on the two machines.

However, even the slightest change on a machine, and subsequent Save,
sometimes (but not always?) changes every Bdesk-File-N link in my database.

Any reason why this is happening?

When I first created the database, and started using this workflow, each
machine had a differently named disk drive. I was puzzled at first, but soon
realized that this is the reason for the volatile file links. So I renamed
the drives to a common name, and I was under the impression that I had
solved the issue. Alas, not so.

Any ideas? I am very tired of having these huge git-diffs every time I
change a single umlaut or something…

Many thanks.

These links also contain alias information, which is unique to a file system, in addition to path information.

Christiaan



Bibdesk-users mailing list
[hidden email]
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-tp7578370p7578371.html

To unsubscribe from Bibdesk-URLs keep changing when I save on different machines, visit

Yannis Rammos

Doctoral Candidate, New York University
[hidden email]
twitter.com/YannisRammos

Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Christiaan Hofman
You can more or less use the old fashioned way by just using fields rather than the linked files in the side panes. Turn off automatic conversion in the preferences. It will be less secure, in particular when you use separate synchronized systems (because you will lose information about the file’s locations). And you will lose some added benefits, because BibDesk is now mainly geared towards linked files and path based fields are deprecated.

Christiaan

On Nov 12, 2015, at 0:33, macula <[hidden email]> wrote:

Thanks, Christiaan. Is it possible to revert to old-fashioned plaintext paths? Clearly, many of us work on more than one machine, with syncing via git, the cloud or some other process, and I'm sure I am not the only one who wishes there was a more ecological way to handle changes. Perhaps a workflow that hasn't occurred to me?

Cheers.

On Nov 12, 2015, at 0:04, macula <a href="x-msg://3/user/SendEmail.jtp?type=node&amp;node=7578372&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email] wrote:

I have two machines with exactly the same folder hierarchy. Even their
respective drives have the same name, the only difference being the host
name, which obviously needs to be unique in the LAN.

I sync the two instances of my database using git and GitHub. All
bibliography reside in my Dropbox and, once again, the paths are identical
on the two machines.

However, even the slightest change on a machine, and subsequent Save,
sometimes (but not always?) changes every Bdesk-File-N link in my database.

Any reason why this is happening?

When I first created the database, and started using this workflow, each
machine had a differently named disk drive. I was puzzled at first, but soon
realized that this is the reason for the volatile file links. So I renamed
the drives to a common name, and I was under the impression that I had
solved the issue. Alas, not so.

Any ideas? I am very tired of having these huge git-diffs every time I
change a single umlaut or something…

Many thanks.

These links also contain alias information, which is unique to a file system, in addition to path information.

Christiaan



Bibdesk-users mailing list
<a href="x-msg://3/user/SendEmail.jtp?type=node&amp;node=7578372&amp;i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
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-tp7578370p7578371.html

To unsubscribe from Bibdesk-URLs keep changing when I save on different machines, visit 

Yannis Rammos

Doctoral Candidate, New York University
<a href="x-msg://3/user/SendEmail.jtp?type=node&amp;node=7578372&amp;i=2" target="_top" rel="nofollow" link="external" class="">[hidden email]
twitter.com/YannisRammos



------------------------------------------------------------------------------

_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

macula
Christiaan,

Allow me to respectfully contest this design decision. I can see the advantages of the "new", alias-based system: links do not break when the file is moved around within a given computer. But then again, they are changed whenever the database is saved on another computer—hardly an uncommon usage scenario in today's mobile, "cloud-y" world. 

That said, Bdsk-File-N links generated on one computer are still valid, not broken, on the other machine. This is   quite curious given that, as you said, some sort of machine-specific info is factored in to generate links. It appears, that is, that there is a one-to-many correspondence between human-readable and machine-readable encodings of the path.

In any case, I need to devise a solution as I cannot let my GitHub-hosted bibliography grow at this explosive rate even after changing a single byte. One possibility would be to replace all Bdsk-File-N links in my database with file:/// URI's, then treat those as Bdsk-URL links (which would allow me to use the handy sidebar to quickly open attachments). In that case I would only need a script that would, perhaps automatically, prepend  "file:///" to the path of the file just dragged-and-dropped. Does this sound reasonable? Has anyone attempted it before? 

All in all, I am willing to sacrifice the ability to safely move files around for the benefit of having a git-friendly workflow.

Many thanks once again.

Christiaan

On Nov 12, 2015, at 0:33, macula <[hidden email]> wrote:

Thanks, Christiaan. Is it possible to revert to old-fashioned plaintext paths? Clearly, many of us work on more than one machine, with syncing via git, the cloud or some other process, and I'm sure I am not the only one who wishes there was a more ecological way to handle changes. Perhaps a workflow that hasn't occurred to me?

Cheers.

On Nov 12, 2015, at 0:04, macula <a href="<a href="x-msg://3/user/SendEmail.jtp?type=node" data-mce-href="x-msg://3/user/SendEmail.jtp?type=node">x-msg://3/user/SendEmail.jtp?type=node&amp;node=7578372&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email] wrote:

I have two machines with exactly the same folder hierarchy. Even their
respective drives have the same name, the only difference being the host
name, which obviously needs to be unique in the LAN.

I sync the two instances of my database using git and GitHub. All
bibliography reside in my Dropbox and, once again, the paths are identical
on the two machines.

However, even the slightest change on a machine, and subsequent Save,
sometimes (but not always?) changes every Bdesk-File-N link in my database.

Any reason why this is happening?

When I first created the database, and started using this workflow, each
machine had a differently named disk drive. I was puzzled at first, but soon
realized that this is the reason for the volatile file links. So I renamed
the drives to a common name, and I was under the impression that I had
solved the issue. Alas, not so.

Any ideas? I am very tired of having these huge git-diffs every time I
change a single umlaut or something…

Many thanks.

These links also contain alias information, which is unique to a file system, in addition to path information.

Christiaan



Bibdesk-users mailing list
<a href="<a href="x-msg://3/user/SendEmail.jtp?type=node" data-mce-href="x-msg://3/user/SendEmail.jtp?type=node">x-msg://3/user/SendEmail.jtp?type=node&amp;node=7578372&amp;i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
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-tp7578370p7578371.html

To unsubscribe from Bibdesk-URLs keep changing when I save on different machines, visit 

You can more or less use the old fashioned way by just using fields rather than the linked files in the side panes. Turn off automatic conversion in the preferences. It will be less secure, in particular when you use separate synchronized systems (because you will lose information about the file’s locations). And you will lose some added benefits, because BibDesk is now mainly geared towards linked files and path based fields are deprecated.

_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users



To unsubscribe from Bibdesk-URLs keep changing when I save on different machines, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Christiaan Hofman

On Nov 12, 2015, at 16:45, macula <[hidden email]> wrote:

Christiaan,

Allow me to respectfully contest this design decision. I can see the advantages of the "new", alias-based system: links do not break when the file is moved around within a given computer. But then again, they are changed whenever the database is saved on another computer—hardly an uncommon usage scenario in today's mobile, "cloud-y" world. 

That said, Bdsk-File-N links generated on one computer are still valid, not broken, on the other machine. This is   quite curious given that, as you said, some sort of machine-specific info is factored in to generate links. It appears, that is, that there is a one-to-many correspondence between human-readable and machine-readable encodings of the path.


The machine-specific (or more exactly file system specific) information is just for part of the data. We save the information in multiple formats. That’s what makes it work and robust. That’s not curious, it’s robust design.

You are thinking from one use case, yours. We have to think from many different use cases, all our users. You have really no idea what some users expect from these links. In fact, there is an open discussion to make it even more robust by following even more information.

In any case, I need to devise a solution as I cannot let my GitHub-hosted bibliography grow at this explosive rate even after changing a single byte. One possibility would be to replace all Bdsk-File-N links in my database with file:/// URI's, then treat those as Bdsk-URL links (which would allow me to use the handy sidebar to quickly open attachments). In that case I would only need a script that would, perhaps automatically, prepend  "file:///" to the path of the file just dragged-and-dropped. Does this sound reasonable? Has anyone attempted it before? 


No, that would not work. We assume that linked files are local URLs and remote URLs are not. So they will probably just be converted to local files.

All in all, I am willing to sacrifice the ability to safely move files around for the benefit of having a git-friendly workflow.

Many thanks once again.


Than you must use fields rather than linked files.

Christiaan

Christiaan

On Nov 12, 2015, at 0:33, macula <[hidden email]> wrote:

Thanks, Christiaan. Is it possible to revert to old-fashioned plaintext paths? Clearly, many of us work on more than one machine, with syncing via git, the cloud or some other process, and I'm sure I am not the only one who wishes there was a more ecological way to handle changes. Perhaps a workflow that hasn't occurred to me?

Cheers.

On Nov 12, 2015, at 0:04, macula <a href="<a href="<a href="x-msg://3/user/SendEmail.jtp?type=node" class="">x-msg://3/user/SendEmail.jtp?type=node" data-mce-href="<a href="x-msg://3/user/SendEmail.jtp?type=node" class="">x-msg://3/user/SendEmail.jtp?type=node"><a href="x-msg://3/user/SendEmail.jtp?type=node&amp;amp;node=7578372&amp;amp;i=0" class="">x-msg://3/user/SendEmail.jtp?type=node&amp;node=7578372&amp;i=0" target="_top" rel="nofollow" link="external" class="">[hidden email] wrote:

I have two machines with exactly the same folder hierarchy. Even their
respective drives have the same name, the only difference being the host
name, which obviously needs to be unique in the LAN.

I sync the two instances of my database using git and GitHub. All
bibliography reside in my Dropbox and, once again, the paths are identical
on the two machines.

However, even the slightest change on a machine, and subsequent Save,
sometimes (but not always?) changes every Bdesk-File-N link in my database.

Any reason why this is happening?

When I first created the database, and started using this workflow, each
machine had a differently named disk drive. I was puzzled at first, but soon
realized that this is the reason for the volatile file links. So I renamed
the drives to a common name, and I was under the impression that I had
solved the issue. Alas, not so.

Any ideas? I am very tired of having these huge git-diffs every time I
change a single umlaut or something…

Many thanks.

These links also contain alias information, which is unique to a file system, in addition to path information.

Christiaan

You can more or less use the old fashioned way by just using fields rather than the linked files in the side panes. Turn off automatic conversion in the preferences. It will be less secure, in particular when you use separate synchronized systems (because you will lose information about the file’s locations). And you will lose some added benefits, because BibDesk is now mainly geared towards linked files and path based fields are deprecated.




------------------------------------------------------------------------------

_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Maxwell, Adam R-2
In reply to this post by macula

> On Nov 12, 2015, at 07:45, macula <[hidden email]> wrote:
>
> Allow me to respectfully contest this design decision. I can see the advantages of the "new", alias-based system: links do not break when the file is moved around within a given computer. But then again, they are changed whenever the database is saved on another computer—hardly an uncommon usage scenario in today's mobile, "cloud-y" world.

It’s shocking that when you save a file, all necessary information is updated? Your real objection here seems to stem from your notion that BibDesk is a text editor, and you think you know what bytes it’s changing. This is not really the case.

> That said, Bdsk-File-N links generated on one computer are still valid, not broken, on the other machine.

No, they’re not, which is why they’re recreated; they’re partially correct, which means they’re partially broken.

> In any case, I need to devise a solution as I cannot let my GitHub-hosted bibliography grow at this explosive rate even after changing a single byte.

What does this mean? Your bibliography file size is not growing at an explosive rate due to these changes. Do you spend a lot of time looking at diffs of it? Is Git really inefficient at storage?

Adam

------------------------------------------------------------------------------
_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

michael.forbes+bibdesk
I would like to emphasize that macula is not alone in these thoughts.

> On Nov 12, 2015, at 8:44 AM, Maxwell, Adam R <[hidden email]> wrote:
>
> It’s shocking that when you save a file, all necessary information is updated? Your real objection here seems to stem from your notion that BibDesk is a text editor, and you think you know what bytes it’s changing. This is not really the case.

Yes: I also have this notion/desire.  For me, a main point of a bibtex database is that it is a text file that can be read by humans, and the Bdsk fields really go against this idea.

>> In any case, I need to devise a solution as I cannot let my GitHub-hosted bibliography grow at this explosive rate even after changing a single byte.
>
> What does this mean? Your bibliography file size is not growing at an explosive rate due to these changes. Do you spend a lot of time looking at diffs of it? Is Git really inefficient at storage?

I do spend a lot of time looking at diffs of my database.  Often I have collaborators who add or edit papers, and need to merge their changes.  The autofilling of papers is fantastic, but the lack of portability, and the noise in the diffs is really a huge wart for users like macula and me.  I believe that a simple option in the preferences for autofilling papers in a relocatable directory structure would satisfy many users needs.

Bibdesk is generally a fantastic piece of software, so I usually just live with this issue, but it bothers me weekly.

Michael.

------------------------------------------------------------------------------
_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Maxwell, Adam R-2

> On Nov 12, 2015, at 09:15, [hidden email] wrote:
>
> I would like to emphasize that macula is not alone in these thoughts.
>
>> On Nov 12, 2015, at 8:44 AM, Maxwell, Adam R <[hidden email]> wrote:
>>
>> It’s shocking that when you save a file, all necessary information is updated? Your real objection here seems to stem from your notion that BibDesk is a text editor, and you think you know what bytes it’s changing. This is not really the case.
>
> Yes: I also have this notion/desire.  For me, a main point of a bibtex database is that it is a text file that can be read by humans, and the Bdsk fields really go against this idea.

You’re not forced to use the Bdsk fields. If you make the choice to put local file locations (whether path or alias-based) in a shared bibtex database, there’s obviously a cost associated with that. Our model was that BibDesk owns the database, and you own the files and can move/rename them manually (unlike iTunes or iPhoto, which owns both).

>
>>> In any case, I need to devise a solution as I cannot let my GitHub-hosted bibliography grow at this explosive rate even after changing a single byte.
>>
>> What does this mean? Your bibliography file size is not growing at an explosive rate due to these changes. Do you spend a lot of time looking at diffs of it? Is Git really inefficient at storage?
>
> I do spend a lot of time looking at diffs of my database.  Often I have collaborators who add or edit papers, and need to merge their changes.  

Okay. Editing existing entries would be confusing in diffs. Adding shouldn't be, since BibDesk always adds in the same location (head of the file, IIRC).

> The autofilling of papers is fantastic, but the lack of portability, and the noise in the diffs is really a huge wart for users like macula and me.  I believe that a simple option in the preferences for autofilling papers in a relocatable directory structure would satisfy many users needs.

Just use the Local-Url field, then, as Christiaan suggested. I think you lose autofile support and the file panes (and renaming/moving in Finder will break your links), but you won’t see the diffs. This basically gives you BibDesk as it was ~8 years ago.

Adam

------------------------------------------------------------------------------
_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

michael.forbes+bibdesk

> On Nov 12, 2015, at 9:32 AM, Maxwell, Adam R <[hidden email]> wrote:
> ...
>> The autofilling of papers is fantastic, but the lack of portability, and the noise in the diffs is really a huge wart for users like macula and me.  I believe that a simple option in the preferences for autofilling papers in a relocatable directory structure would satisfy many users needs.
>
> Just use the Local-Url field, then, as Christiaan suggested. I think you lose autofill support

... Nooooo!  Autofile is a fabulous feature.  I still want Bibdesk to autofile the papers, but after it autofiles them, I want it to fill in the Local-Url field and then be done with it.  This is why I just live with the noise so far.

> and the file panes (and renaming/moving in Finder will break your links)

I can live with that.

Michael.
------------------------------------------------------------------------------
_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

macula
First off, I should not give the wrong impression. Gratitude is due to
Adam et. al. on this forum for a bibliography manager, and support
community, that is by far best-in-class, and graciously offered for
free.

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. I just feel that the new
BibDesk is somehow rubbing against the aesthetic and openness of the
Bib(La)TeX format. 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.

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?

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.

Thanks.

>> On Nov 12, 2015, at 9:32 AM, Maxwell, Adam R <[hidden email]>
>> wrote:
>> ...
>>> The autofilling of papers is fantastic, but the lack of portability,
>>> and the noise in the diffs is really a huge wart for users like
>>> macula and me.  I believe that a simple option in the preferences
>>> for autofilling papers in a relocatable directory structure would
>>> satisfy many users needs.
>>
>> Just use the Local-Url field, then, as Christiaan suggested. I think
>> you lose autofill support
>
> ... Nooooo!  Autofile is a fabulous feature.  I still want Bibdesk to
> autofile the papers, but after it autofiles them, I want it to fill in
> the Local-Url field and then be done with it.  This is why I just live
> with the noise so far.
>
>> and the file panes (and renaming/moving in Finder will break your
>> links)
>
> I can live with that.
>
> Michael.
> ------------------------------------------------------------------------------
> _______________________________________________
> Bibdesk-users mailing list
> [hidden email]
> 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-tp7578370p7578379.html
>
> To unsubscribe from Bibdesk-URLs keep changing when I save on
> different machines, visit
>
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

macula
In reply to this post by michael.forbes+bibdesk
By the way, anyone knows how to convert the links back into path fields? I tried a script available on GitHub but the output triggered errors and warnings in Bibdesk.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Christiaan Hofman

On Nov 13, 2015, at 17:55, macula <[hidden email]> wrote:

By the way, anyone knows how to convert the links back into path fields? I
tried a script available on GitHub but the output triggered errors and
warnings in Bibdesk.

Thanks.

There’s an applescript for that linked on the Wiki.

Christiaan


------------------------------------------------------------------------------

_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Adam Maxwell
In reply to this post by macula

> On Nov 13, 2015, at 04:05 , macula <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

macula

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 [hidden email] 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
[hidden email]
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

Yannis Rammos

Doctoral Candidate, New York University
[hidden email]
twitter.com/YannisRammos

Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Adam R. Maxwell

> On Nov 13, 2015, at 12:06 , macula <[hidden email]> wrote:
>
> 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.

One problem: suppose you have multiple files with the same reference in them (as I do; one file per research area, more-or-less). What is your primary key to that database? What happens if you use a text editor to copy an entry between files? What are the semantics of drag-and-drop of entries between files? What happens when you have multiple files open for editing? I could go on :).

> 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.

Thanks! It's helpful to have some numbers; I was unclear about the size problem you mentioned.

--
Adam




------------------------------------------------------------------------------
_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Christiaan Hofman
In reply to this post by Adam Maxwell

On Nov 13, 2015, at 20:52, Adam R. Maxwell <[hidden email]> wrote:


On Nov 13, 2015, at 04:05 , macula <[hidden email]> 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


------------------------------------------------------------------------------

_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Christiaan Hofman

On Nov 13, 2015, at 23:23, Christiaan Hofman <[hidden email]> wrote:


On Nov 13, 2015, at 20:52, Adam R. Maxwell <[hidden email]> wrote:


On Nov 13, 2015, at 04:05 , macula <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Fischlin  Andreas
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


+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 <[hidden email]> wrote:


On Nov 13, 2015, at 23:23, Christiaan Hofman <[hidden email]> wrote:


On Nov 13, 2015, at 20:52, Adam R. Maxwell <[hidden email]> wrote:


On Nov 13, 2015, at 04:05 , macula <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users


------------------------------------------------------------------------------

_______________________________________________
Bibdesk-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
Reply | Threaded
Open this post in threaded view
|

Re: Bibdesk-URLs keep changing when I save on different machines

Christiaan Hofman
That does not address the issues discussed here in any way. The problem is not that the paths are different. The OP had that covered, as he was even using the exact same paths on both systems (not even through symlinks). It’s not the path where the system specific information comes in. The file system specific information is not in the path, it’s in the alias data that BibDesk saved in the Bdsk-File-* fields. And the point is that this means that these fields change whenever you save from a different file system from the previous time.

Christiaan

On Nov 19, 2015, at 13:09, Fischlin Andreas <[hidden email]> wrote:

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


+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 <[hidden email]> wrote:


On Nov 13, 2015, at 23:23, Christiaan Hofman <[hidden email]> wrote:


On Nov 13, 2015, at 20:52, Adam R. Maxwell <[hidden email]> wrote:


On Nov 13, 2015, at 04:05 , macula <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
12