Update algorithm when moving the reflib file...

[Michael R. Head]

Hi, I love Referencer. It's just what I've been looking for.

One problem I'm facing is that I'm keeping my referencer files and the
associated PDFs in CVS and it may be checked out into many different
locations on different machines. The reflib file cleverly stores both
the full path and relative path of the PDF. Unfortunately for me, the
way these are updated when the reflib file moves causes a (small)
headache).

When the reflib file moves, the algorithm seems to be this:
1. Check if the file exists at the full path
2. If it is, compare the full path and the current reflib location
3. If they differ toss the relative location and use the full path

It does this even if the relative filename also refers to the file. I
guess that for my situation, the relative location should be preferred.
--
Michael R. Head <burner at suppressingfire.org>
http://www.suppressingfire.org/~burner/
http://suppressingfire.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/referencer/attachments/20070415/109902a1/attachment.bin>

[John Spray]

On Sun, 2007-04-15 at 14:48 -0400, Michael R. Head wrote:b

Post by Michael R. Head
1. Check if the file exists at the full path
2. If it is, compare the full path and the current reflib location
3. If they differ toss the relative location and use the full path
It does this even if the relative filename also refers to the file. I
guess that for my situation, the relative location should be preferred.

I'm not sure I completely understand the problem. Is the original
relative path is getting lost? This shouldn't be happening if the
document file still exists in a subfolder of where the reflib file is.

John

[Michael R. Head]

Post by John Spray
On Sun, 2007-04-15 at 14:48 -0400, Michael R. Head wrote:b

Post by Michael R. Head
1. Check if the file exists at the full path
2. If it is, compare the full path and the current reflib location
3. If they differ toss the relative location and use the full path
It does this even if the relative filename also refers to the file. I
guess that for my situation, the relative location should be preferred.

I'm not sure I completely understand the problem. Is the original
relative path is getting lost? This shouldn't be happening if the
document file still exists in a subfolder of where the reflib file is.

Hi, yeah, that's what's happening. Here's the sequence of operations
leading to this result:

1) create folder Papers/conference-2006/References
2) put pdfs in that folder and use Referencer to create a .reflib file
in that directory
3) cp -r Papers/conference-2006 Papers/conference-2007
4) open Papers/conference-2007/References/refs.reflib
5) add some new entries and save the result
6) examine the .reflib file and note that the relative paths to the
files are gone and absolute paths point to the copies
Papers/conference-2006/References, rather than in *-2007/*

Here are two revisions of the file found in CVS 1.2 is the one that
Referencer saved after I opened the copied file (version 1.1.1.1).
http://firefighter.cs.binghamton.edu/cgi-bin/viewcvs.cgi/parallelxml-grid-2007/References/references.reflib?rev=1.2&view=markup
http://firefighter.cs.binghamton.edu/cgi-bin/viewcvs.cgi/parallelxml-grid-2007/References/references.reflib?rev=1.1.1.1&view=markup

After tweaking things a bit (re-copying the reflib file over and moving
the old parallelxml-hpdc-socp-2007 folder out of the way, opening the
reflib file and saving it), here's what I got, which is what I wanted
Referencer to do in the first place:
http://firefighter.cs.binghamton.edu/cgi-bin/viewcvs.cgi/parallelxml-grid-2007/References/references.reflib?rev=1.3&view=markup

Post by John Spray
John

--
Michael R. Head <burner at suppressingfire.org>
http://www.suppressingfire.org/~burner/
http://suppressingfire.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/referencer/attachments/20070430/3a7f1519/attachment.bin>

[John Spray]

Post by Michael R. Head
Hi, yeah, that's what's happening. Here's the sequence of operations
1) create folder Papers/conference-2006/References
2) put pdfs in that folder and use Referencer to create a .reflib file
in that directory
3) cp -r Papers/conference-2006 Papers/conference-2007
4) open Papers/conference-2007/References/refs.reflib
5) add some new entries and save the result
6) examine the .reflib file and note that the relative paths to the
files are gone and absolute paths point to the copies
Papers/conference-2006/References, rather than in *-2007/*

Okay, I understand what's going on now. As a first step I've committed
a patch which causes the relative paths not to be thrown away. Beyond
this I will consider how to modify the behaviour, possible some UI for
resolving ambiguities.

Regards,
John

[Michael R. Head]

Post by John Spray
Okay, I understand what's going on now. As a first step I've committed
a patch which causes the relative paths not to be thrown away. Beyond
this I will consider how to modify the behaviour, possible some UI for
resolving ambiguities.

Cool. Thanks!

mike

Post by John Spray
Regards,
John

--
Michael R. Head <burner at suppressingfire.org>
http://www.suppressingfire.org/~burner/
http://suppressingfire.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/referencer/attachments/20070430/d862319e/attachment.bin>

[John Spray]

Post by John Spray
Okay, I understand what's going on now. As a first step I've committed
a patch which causes the relative paths not to be thrown away. Beyond
this I will consider how to modify the behaviour, possible some UI for
resolving ambiguities.

The version now in subversion now checks for situations where the
relative filename and absolute filename point to different (existing)
files. In this case it provides a dialog asking the user whether he
would like to keep the existing absolute path, or replace it with the
filename derived from the relative path.

Testing would be appreciated.

John