If the book has it wrong with the --revprop example, what should the
example be?
Yes, for my working copy, I used the other example.
It was pointed out that with CVS you had to specifically tell it which
files were binary and with SVN you tell it which files are text. Well,
for me, the CVS method is better. Why? Because we have Unix scripts that
are obviously text files (they are scripts afterall :-), but they have no
extensions. Program names with extension is a MicroCrap thing afterall.
While I can obviously add *.c, *.cc and *.h lines in the
.subversion.config to handle those text files, the tons of other text
scripts that we have would be cumbersome to maintain in the config file.
That is why the wildcard, * only, line in the config was required. The
requirement that subversion correctly not muck binary files with
svn:keywords is pretty much a given.
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?
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?
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 05:15 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 didn't find anything in the book (printed) that said keywords won't be
> screwed with if the file is listed as binary.
I looked and didn't see anything either.
>
> > 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.
Yes, page 215 is describing the correct subcommand (propdel), but the
command is using incorrect command line flags. The --revprop only
operates on properties that are for the entire revision, not for any
files or directories in the repository.
You can't remove or change file or directory properties without doing so
in your working copy and then commit.
> You still need to run
>
> svn pd svn:keywords ...../libOrbitPlugin.2.0g.so
>
> I said that I did.
Without the --revprop flag.
> 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.
Yes! Typo there.
> 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.
Yes, to prevent commits that mix properties, you'll need a pre-commit
hook script.
Regards,
Blair
--
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/
Received on Fri May 20 19:55:55 2005