Re: [Jabref-users] Real-time Database Connectivity

[Lee P. <pat...@wr...>]

Adam Montville wrote:
> .
> [[AWM]] At this point, my group is fairly well-versed in SVN, but I can easily see where other groups may not be.  So, an SVN plug-in, while useful, may not be the ultimate goal.  I would like to see JabRef handle "closed" reference sharing and "open" reference sharing, where closed sharing would be akin to "you can read my bibtex, but don't dare write to it!" and open sharing would be "let's compile a common list of references to which we can all add and from which we can all read."
>
>   
I like Adam's suggestion of "open" and "closed" sharing.  Right now, I'm 
leaning towards an SVN-base solution.  Here's why:

The term "sharing" can mean two different things.  In one sense, 
"sharing" can mean "publishing," in that you make your bibtex file 
available to others to search.  In its simplest form, this could be 
accomplished by emailing your bibtex file to the team. A slightly better 
way might be committing your changes to a common repository (with read 
only access by other team members) from which others can pull a copy.   
In any case, publishing implies that others cannot search unless you 
make it available.  Another sense of "sharing" can mean that others can 
look at your most recent changes any time they like.  The only way this 
can happen is: 1) you share a common network drive or 2) you have a 
server that serves the file to them.   I do not think we want to assume 
a shared network drive, and I don't think we want to write JabRef server 
code.  Theoretically, JabRef  could save to a local DB or SVN 
repository, and each team member could have an account on every other 
team member's server, but I think the logistics of that make this 
approach a non-starter.  So, I think a centralized system to which each 
user publishes his work is the best solution.   (Alternatively, you 
could use a distributed system like GIT, but that's another issue.)

The two centralized systems we're considering are a SQL DB and SVN.  The 
main problem with a SQL DB is that there is no way to rationally merge 
conflicts.   So, a SQL DB approach would have to take this into 
account.   This additional overhead is not incurred in an SVN-based 
solution.   As for the SVN repo installation/maintenance burden for the 
user:  such a burden will be incurred by any server solution, and SVN is 
easy to install and maintain.

Anyway, these comments are just me thinking out loud.

Cheers,
 Lee

P.S., I agree with Torsten.  I use SVN to sync my bibtex file between a 
linux box and a Windows box.  I use the command line under linux, and 
tortoiseSVN under windows.  The solution works just fine for me.   
Building SVN client functionality into JabRef does not add any 
functionality that cannot be easily achieved by using a standalone SVN 
client, it only streamlines the solution.