Blair:
Thanks for responding, comments below, thanks to stupid Lotus Bloats idea
of how to answer e-mail.
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/20/2005 02:14 PM
To
Michael L Brown/MSN/MS/PHILIPS@PHILIPS
cc
users@subversion.tigris.org
Subject
Re: Binary file checkin problem
Classification
>> 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.
OK, I won't do that anymore.
>> 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.
By client I am assuming you mean the person who did the add/commit. In
this case, for our needs, the setting of svn:keywords needs to be
transparent. We can't rely upon the programmer remembering to set the
property.
>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.
See the previous paragraph's response. Since we are not having the
programmer deal with svn:keywords, having it fail will result in the
programmer not knowing what to do. Again, the idea is to try and make
the properties setting transparent to the programmer. SVN is a tool
for our code base. Computers are supposed to help us with the manual
tasks and property setting is a manual task that can be figured out
by SVN.
>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.
You are quite correct in this post. I do not know how SVN determines
if a file is binary, or not, but we have files that start out with a
bunch of text and then has embedded binary data.
>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.
See above regarding this.
As for testing files that do not have an extension, it isn't that hard.
Doing a "file filename" on a shell script will result in
"executable shell script" being returned. If the file ends in .c, .cc
or .h, the script can exit in the affirmative and let the auto-props
do its part. Then again, by having the hook script even set the
svn:keywords property on those extensions, it will eliminate the
problem of the user not having a correct .subversion/config file, since
there isn't a repository dependent master config file, with override
settings.
I'm trying to remember our code base, but I do not think we have keywords
in anything other than .c, .cc, .h and shell-script files.
>> 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.
How will this tell me if a binary file got butchered? Unless there is
a keyword pattern in the binary file, it will not have been touched.
>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.
I will for new adds (see above), i.e., using a commit hook.
One final question. I must have misread the book, or at least didn't
correctly understand it. I'm under the impression that the svn:keywords
property doesn't actually modify the committed file, i.e., if there is
a keyword in the file, it isn't changed. The change is when the file
is checked out/updated, i.e., the keyword is modified when the working
copy is created.
If this is the case, why would binary files be "damaged" in the actual
repository? One would think thay by removing the svn:keywords
property, removing the working copy and then doing an update would
"repair" the working copy. But that does not seem to be the case.
Did I miss something?
MB
Received on Mon May 23 18:22:44 2005