[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Binary file checkin problem

From: Blair Zajac <blair_at_orcaware.com>
Date: 2005-05-19 22:11:58 CEST

Michael L Brown wrote:
> >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.

That's a good point. However, it does appear that Subversion will do
substituions on binary files. This should that you will get replacement
on a file with a binary svn:mime-type:

svnadmin create repos
svn co file://`pwd`/repos wc
cd wc
cp /etc/group .
cat > test <<'END'
# $HeadURL: $
# $LastChangedRevision: $
# $LastChangedDate: $
# $LastChangedBy: $
# $Id: $

Hello there
svn --config-dir / add test
svn ps svn:mime-type application/octet-stream test
svn commit -m ''
svn update
svn ps svn:keywords 'HeadURL LastChangedBy LastChangedDate
LastChangedRevision Id' test
echo "extra line" >> test
svn commit -m ''
svn update
cat test

> 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?

You may want to use autoprops and not set svn:keywords on everything,
just on the files you know are source files.

> 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

You're trying to remove a revision property when you should be changing
a file property. There is no special meaning to a revision property of
svn:keywords. Also, you can't change the file already in the
repository, so your best bet is to update to HEAD, remove the property
with 'svn pd svn:keywords ...../libOrbitPlugin.2.0g.so' and then copy in
a known good copy.

> 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.

Right, it's a file property, not a per-revision property. And you can't
change a per-file property without a new commit.

> 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.

You still need to run

svn pd svn:keywords ...../libOrbitPlugin.2.0g.so

and probably should run it on all binary files you have in your repository.

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

Change your procedures so you only apply svn:keywords to everything in
the repository.


Blair Zajac, Ph.D.
Subversion and Orca training and consulting
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 19 22:13:57 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.