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

[macula]

On 20 Nov 2015, at 2:25, Mark Brown [via bibdesk users] wrote:

> Perhaps the large git diff is due to git treating the .bib as binary? 
> I don't see much benefit in my workflow for using git on bib desk, so 
> I am not sure if it does this or not, but for small changes in Java 
> apps I write, the git diff can be huge on .jar files
>
> --
> Mark Brown
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

No, git treats the bib file as the text file that it is.


> On Thursday, November 19, 2015 at 4:15 PM, Christiaan Hofman wrote:
>
>>
>>> On Nov 19, 2015, at 17:59, Maxwell, Adam R >> (mailto:adam.maxw...@pnnl.gov)> wrote:
>>>
 On Nov 19, 2015, at 02:44, Christiaan Hofman >>> (mailto:cmhof...@gmail.com)> wrote:

 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.
>>>
>>> Just spitballing, but the only safe way I see to make it an actual 
>>> pref is by adding a new field type (like Bdsk-Path-n) and doing a 
>>> conversion process when opening and saving.
>>>
>>> --
>>> Adam
>>
>> Why? I don’t get that. The data would be forward compatible, and 
>> also be compatible between the situation with or without the option. 
>> The data will be of the same format, it’s just how many versions of 
>> the file will be saved in the dictionary. So the relative path would 
>> always be saved, while the alias will only be saved when the option 
>> is not set. If you’d think saving just the relative path is too 
>> fragile, than adding a new field type would not solve anything, 
>> because that would be the exact same. BTW, the only reason this would 
>> not be backward compatible is because the data without alias was 
>> explicitly rejected previously, not because the code could not have 
>> handled it.
>>
>> Christiaan
>> --
>> ___
>> Bibdesk-users mailing list
>> 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
>
>
>
>
> ___
> 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-tp7578370p7578395.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=




--
View this message in context: 
http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370p7578396.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

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

[Mark Brown]

Perhaps the large git diff is due to git treating the .bib as binary? I don't 
see much benefit in my workflow for using git on bib desk, so I am not sure if 
it does this or not, but for small changes in Java apps I write, the git diff 
can be huge on .jar files  

--  
Mark Brown
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, November 19, 2015 at 4:15 PM, Christiaan Hofman wrote:

>  
> > On Nov 19, 2015, at 17:59, Maxwell, Adam R  > (mailto:adam.maxw...@pnnl.gov)> wrote:
> >  
> > > On Nov 19, 2015, at 02:44, Christiaan Hofman  > > (mailto:cmhof...@gmail.com)> wrote:
> > >  
> > > 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.
> >  
> > Just spitballing, but the only safe way I see to make it an actual pref is 
> > by adding a new field type (like Bdsk-Path-n) and doing a conversion 
> > process when opening and saving.
> >  
> > --  
> > Adam
>  
> Why? I don’t get that. The data would be forward compatible, and also be 
> compatible between the situation with or without the option. The data will be 
> of the same format, it’s just how many versions of the file will be saved in 
> the dictionary. So the relative path would always be saved, while the alias 
> will only be saved when the option is not set. If you’d think saving just the 
> relative path is too fragile, than adding a new field type would not solve 
> anything, because that would be the exact same. BTW, the only reason this 
> would not be backward compatible is because the data without alias was 
> explicitly rejected previously, not because the code could not have handled 
> it.
>  
> Christiaan  
> --
> ___
> Bibdesk-users mailing list
> 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

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

[Christiaan Hofman]

> On Nov 19, 2015, at 17:59, Maxwell, Adam R  wrote:
> 
> 
>> On Nov 19, 2015, at 02:44, Christiaan Hofman  wrote:
>> 
>> 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.
> 
> Just spitballing, but the only safe way I see to make it an actual pref is by 
> adding a new field type (like Bdsk-Path-n) and doing a conversion process 
> when opening and saving.
> 
> -- 
> Adam


Why? I don’t get that. The data would be forward compatible, and also be 
compatible between the situation with or without the option. The data will be 
of the same format, it’s just how many versions of the file will be saved in 
the dictionary. So the relative path would always be saved, while the alias 
will only be saved when the option is not set. If you’d think saving just the 
relative path is too fragile, than adding a new field type would not solve 
anything, because that would be the exact same. BTW, the only reason this would 
not be backward compatible is because the data without alias was explicitly 
rejected previously, not because the code could not have handled it.

Christiaan

--
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[Maxwell, Adam R]

> On Nov 19, 2015, at 09:26, Fischlin Andreas  
> wrote:
> 
> I am not convinced that a new field type is necessary here for several 
> reasons:

okay

> What happens if you should have both fields in a record?

That would only happen if you added them with a text editor. Anyway, I’m 
talking about storage and backwards compatibility/preservation of user data. 
Absolute vs. relative path resolution that you’re talking about is a separate 
issue.

-- 
adam

--
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[Fischlin Andreas]

I am not convinced that a new field type is necessary here for several reasons: 
What happens if you should have both fields in a record? Why supporting files 
to be anywhere in case of relative paths? I believe that most use cases 
interested in a relative path need only a common root path to which to 
concatenate the relative path. Thus one could enforce such a common root (for 
this new hidden pref) and always extract the wanted relative path from an 
absolute path as contained in the existing field type. Following some rules, 
e.g. using the global pdf repository path as that common root, would already 
suffice to define what part of the absolute path is to be ignored. 

Regards, Andreas 

ETH Zurich, Prof. Dr. Andreas Fischlin, Systems Ecology
CHN E 21.1, Universitaetstrasse 16, 8092 Zurich, SWITZERLAND
Tel: +41 44 633-6090 - Mobile: +41 79 595-4050 - 
mailto:andreas.fisch...@env.ethz.ch
www.sysecol.ethz.ch/people/afischli

> On 19 Nov 2015, at 18:01, Maxwell, Adam R  wrote:
> 
> 
>> On Nov 19, 2015, at 02:44, Christiaan Hofman  wrote:
>> 
>> 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.
> 
> Just spitballing, but the only safe way I see to make it an actual pref is by 
> adding a new field type (like Bdsk-Path-n) and doing a conversion process 
> when opening and saving.
> 
> -- 
> Adam
> 
> 
> --
> ___
> Bibdesk-users mailing list
> 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

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

[Maxwell, Adam R]

> On Nov 19, 2015, at 02:44, Christiaan Hofman  wrote:
> 
> 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.

Just spitballing, but the only safe way I see to make it an actual pref is by 
adding a new field type (like Bdsk-Path-n) and doing a conversion process when 
opening and saving.

-- 
Adam


--
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[macula]

>> On Nov 13, 2015, at 23:23, Christiaan Hofman  
>> wrote:
>>
>>>
>>> On Nov 13, 2015, at 20:52, Adam R. Maxwell >> > wrote:
>>>
>>>
 On Nov 13, 2015, at 04:05 , macula >>> > 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 th

Re: [Bibdesk-users] 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  
> 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
> 
> andreas.fisch...@env.ethz.ch 
> 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  > wrote:
> 
>>> 
>>> On Nov 13, 2015, at 23:23, Christiaan Hofman >> > wrote:
>>> 
 
 On Nov 13, 2015, at 20:52, Adam R. Maxwell >>> > wrote:
 
 
> On Nov 13, 2015, at 04:05 , macula 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

Re: [Bibdesk-users] 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

andreas.fisch...@env.ethz.ch
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 
mailto:cmhof...@gmail.com>> wrote:


On Nov 13, 2015, at 23:23, Christiaan Hofman 
mailto:cmhof...@gmail.com>> wrote:


On Nov 13, 2015, at 20:52, Adam R. Maxwell 
mailto:amaxw...@me.com>> wrote:


On Nov 13, 2015, at 04:05 , macula 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. 

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

[Christiaan Hofman]

> On Nov 13, 2015, at 23:23, Christiaan Hofman  wrote:
> 
>> 
>> On Nov 13, 2015, at 20:52, Adam R. Maxwell > > wrote:
>> 
>> 
>>> On Nov 13, 2015, at 04:05 , macula 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

---

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

[Christiaan Hofman]

> On Nov 13, 2015, at 20:52, Adam R. Maxwell  wrote:
> 
> 
>> On Nov 13, 2015, at 04:05 , macula  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[Adam R. Maxwell]

> On Nov 13, 2015, at 12:06 , macula  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] 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  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=aXIyOTlAbWUuY29tfDc1NzgzNzB8LTE

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

[Adam R. Maxwell]

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

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

[Christiaan Hofman]

> On Nov 13, 2015, at 17:55, macula  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[macula]

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.



--
View this message in context: 
http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370p7578381.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

Re: [Bibdesk-users] 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  
>> 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
>
> ... No!  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
> 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-tp7578370p7578379.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=





--
View this message in context: 
http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370p7578380.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

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

[michael . forbes+bibdesk]

> On Nov 12, 2015, at 9:32 AM, Maxwell, Adam R  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

... No!  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[Maxwell, Adam R]

> On Nov 12, 2015, at 09:15, michael.forbes+bibd...@gmail.com 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  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] 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  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[Maxwell, Adam R]

> On Nov 12, 2015, at 07:45, macula  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

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

[Christiaan Hofman]

> On Nov 12, 2015, at 16:45, macula  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 >> data-mce-href="x-msg://3/user/SendEmail.jtp?type=node">x-msg://3/user/SendEmail.jtp?type=node&node=7578372&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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] 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 [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 
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


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-tp7578370p7578373.html
To unsubscribe from Bibdesk-URLs keep changing when I save on different 
machines, click here.
NAML



--
View this message in context: 
http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370p7578374.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

Re: [Bibdesk-users] 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  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 [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 

--
___
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

Re: [Bibdesk-users] 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  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
> 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-tp7578370p7578371.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-tp7578370p7578372.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

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

[Christiaan Hofman]

> On Nov 12, 2015, at 0:04, macula  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
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users

[Bibdesk-users] 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.





--
View this message in context: 
http://bibdesk-users.661331.n2.nabble.com/Bibdesk-URLs-keep-changing-when-I-save-on-different-machines-tp7578370.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