On Aug 19, 2004, at 11:38 PM, Thomas Naughton wrote:
After the call on monday I tried to build the 'oscarpkg-howto' so I could
post a copy on the web. I soon realized that the make was tanking and put
it aside for lack of time.
Tonight I realized it was b/c the figs/*.png files were in ASCII. Instead
of figuring out how to edit properties, I just copied some files I had from
a previous CVS checkout and all built properly.
As you mentioned below, yes, I did fix this on Monday.
Then I did a 'svn ci' (and a 'svn commit'). But I didn't get any output
and wasn't prompted to enter a log message.
If you didn't get prompted for anything, what happened?
However when I did a fresh checkout to see if things were actually there, the properties had an updated timestamp (Thu, 19 Aug 2004).
I'm not sure if I fixed things or if this was Jeff's fix from Monday,
----------------------------------------------------------------------- -
r2583 | jsquyres | 2004-08-16 15:26:19 -0400 (Mon, 16 Aug 2004) | 2 lines
Previous png files were imported incorrectly (ASCII). Fixed.
If indeed this was fixed on Monday, what should I have done to bring my previous checkout up to date? 'svn update' didn't seem to work.
I think that this may actually be a SVN bug -- I meant to send something to the list about it (sorry). I'll explain more below, but I found that the following worked:
cd oscar (your SVN top-level dir) rm -rf docs svn up
That is, remove all the docs and then re-check them out. More specifically, you can be a little more fine-grained about your approach (e.g., perhaps just remove the howto directory), but removing an entire *directory* is important here. Alternatively, you can update the directory to a different revision (one that changes all the graphics) and then update it to the head again, and it should have the same effect.
What I'm pretty sure is happening is that SVN is *not* re-downloading the files in binary mode when the properties are updated. This is because SVN keeps a copy of the file cached/hidden in the .svn directory so that you can do things like "svn diff" and "svn revert" without requiring network access. So when we updated the properties, if you just "rm foo.png; svn up", it'll just copy over the cached file -- which was probably downloaded in ASCII mode. So you really need to ditch the cached copy and force SVN to re-download in binary mode. The two ways to do this:
- remove the entire directory where the file was (including its .svn meta directory) and force a re-download of everything
- svn up to a different revision that changes the files in question (i.e., re-download to the cache) and then svn up to the head again
I *think* that this is what is happening, but I didn't get a chance to test this theory.
Also, do property edits have associated log msgs?
Yes, they do. IIRC, that log message is from my commit of the property changes.
*Hypothetically*, I could have just changed the properties and then forced a re-download and all would have been well (i.e., I think that SVN always stores things in binary mode, regardless of ascii/binary...?). But I didn't realize this at the time, so I didn't test it -- and therefore committed both corrected PNG files and new properties.
I'l try this out in a demo SVN repository (we have one for such purposes ;-) ), and see what happens.
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
