[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: Michael L Brown <michael.l.brown_at_philips.com>
Date: 2005-05-19 23:53:57 CEST

I didn't find anything in the book (printed) that said keywords won't be
screwed with if the file is listed as binary.

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

What I did is directly from the book, page 215 of the printed version,
complete reference section.

You still need to run

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

I said that I did.

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

Unfortunately, that won't fix any bad ones that are there. I'll have to
find the bad ones and fix them up, one by one.

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

I think you mean to only apply it to text files that are checked in.

Nice idea, but here is where SVN falters... no master config file and no
master config file that would override any user config file. If I create
a new config file and send out e-mail telling users to install it over
their current config file, it might not get done. The fact that there
isn't a master config in the repository area that is the end all to be
all, is a real problem. Depending on users to keep their local copies
up-to-date is not realistic.

I'm guessing that I now need to figure out how to do this via a hook
script.

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 03:11 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:
>
> >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
END
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.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/
Received on Thu May 19 23:56:48 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.