Re: Binary file checkin problem

>You never want to set svn:keywords on a binary file, only source text
>files. You may get replacements to occur that you don't want to that
>will screw up the file.

Unless I got misdirected somewhere, when a file is considered binary,
keywords are supposed to be ignored, i.e., no substitution done. It
certainly works that way in CVS.

If SVN does ignore the fact that a file is binary, and blindly does
keyword substitution then I feel that we have a design flaw. The major
problem... there isn't a system wide config file that can be created that
will override user config files. To have to create some kind of checkin
hook script that looks for something that SVN does naturally is silly,
i.e., recreating the wheel. To have to create a script that does binary
file checking and then decide to set the keyword property is overkill.
Everything is already there in SVN. Why should users have to recreate that
process?

My guess is that a string $Id: $ got matched and replaced.

There isn't that, but a strings did find: $Revision: 1.26 $

Crap.

I just tried the following and it blew up in my face:

svn propdel keywords --revprop -r 5
svn+rsh://rtpsvr1/ThirdPartyTools/trunk/Plugins/RaySearch/libOrbitPlugin.2.0g.so
svn: Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook

OK, so I went into the hooks directory for this repository and set up the
correct hook. I then did it again (after changing "keywords" to
"svn:keywords"). This time it was accepted. I then removed my working
copy and did an update. But the proplist says that keywords is still
there.

So, I then did the propdel on the working copy and removed and updated it.
 No more keywords for the file. But, now the file is wrong by 8 bytes.

Finally, I grabbed a backup copy from a different area and committed it.
The byte size came out correct.

Whew! But, what needs to be done to keep this from happening again?

MB
 --
Mike Brown (Michael.L.Brown@Philips.com)
            Lotus Bloats: Michael L Brown/MSN/MS/PHILIPS
Philips/ADAC, Madison, WI
Desk: 608-288-6969 Fax: 608-298-2101
PMS direct: 164-6969
You design it, I'll build it!

Blair Zajac
05/19/2005 01:51 PM

To
Michael L Brown/MSN/MS/PHILIPS@PHILIPS
cc
users@subversion.tigris.org
Subject
Re: Binary file checkin problem
Classification

Michael L Brown wrote:
>
> I know, checking in binary files can be a crap shoot, but didn't think
> it would be this easy to actually have it happen.

It's not a crap shoot. I check in images all the time into Subversion.

> Take the following example:
>
> svn proplist -v libOrbitPlugin.2.0g.so
> Properties on 'libOrbitPlugin.2.0g.so':
> svn:executable :
> svn:mime-type : application/octet-stream
> svn:keywords : Id LastChangedDate LastChangedRevision LastChangedBy
> HeadURL
>
> The working copy is now 3 bytes smaller than the original and fails when

> it is used: Format error: shdr table truncated
>
> Is there a cure that can fix this checked in file and to keep it from
> affecting all binary files? Doesn't SVN consider .so files as being
> binary?

You never want to set svn:keywords on a binary file, only source text
files. You may get replacements to occur that you don't want to that
will screw up the file.

Try running cmp on the original and the screwed up file and see where
the first difference is. It'll tell you which byte into the file is
different. Load the messed up libOrbitPlugin.2.0g.so into an editor and
move forward that many bytes to see what the difference is.

My guess is that a string $Id: $ got matched and replaced.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/