> On Nov 12, 2015, at 16:45, macula <ir...@me.com> 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:/// <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:/// <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="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&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
