[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-20 21:14:11 CEST

Michael L Brown wrote:
>
> If the book has it wrong with the --revprop example, what should the
> example be?

The book has it right, there are two distinct types of properties (per
revision and per path) and you use the --revprop to change the per
revision properties.

> The problem I am saddled with is that we are live with Subversion and we
> are still figuring this stuff out. I did not want us to go live until
> this kind of stuff is worked out. I was told, bring it up, now.
>
> So, until Subversion no longer mucks up binary files with textual
> properties, I have to build a commit script to check the file type and
> set the svn:keywords property if it determines that the file is a
> textual file. My other problem... I haven't a clue on how to set
> svn:keywords in a commit script and have it override a user's config
> file. Also, is it a post or pre commit script function? Are there
> examples somewhere?

It's not a good idea to have the commit script change the commit because
the client has no way of knowing that something has changed in the commit.

My recommendation for now is to have a pre-commit script that checks if
a file has a svn:mime-type of binary (that is svn:mime-type is not set
or it is set and doesn't start with text/) and has svn:keywords or
svn:eol-stype set and abort the commmit if it does.

Also, the test for a text file may produce incorrect results (it may
think a file is text when it is in fact binary). I can't think of any
examples, but it is possible.

I don't recommend just throwing svn:keywords on every file you have to
commit either. So my recommendation is to have autoprops for files
matching *.c *.h *.sh and the Subversion users manually set svn:keywords
on text files with no file extension.

> Lastly I have no idea if other binary files have been corrupted or not.
> I'm coming to the conclusion that I should take the latest working
> copy, blow away all of the .svn directories, replace known binary files
> with known good copies from the old CVS repository (they won't have
> changed), rename the current repository and then import the new working
> copy (after the commit hook scripts are known to be working). Am I
> doing overkill or not?

Here's what I recommend:

1) The first step is to check out a working copy and remove all the
svn:keywords from binary files that shouldn't have them in the first
place. Then I would do a commit with just property changes.

2) Then with the working copy, just copy over the good files from the
CVS repository into the Subversion working copy.

3) Out of interest, run 'svn status' to see which files got messed up.

4) Commit.

That should be all you need to do.

And you don't need any commit hooks to do this. You also don't need a
new repository.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 20 21:16:21 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.