Michael L Brown <email@example.com> writes:
> Ya, I remember you saying this once before, that is why I did the
> auto-prop thing and used a wild card because you said that propset
> wouldn't be done on binary files. Obviously that is not the case,
> because the importation of the binary file indeed had the keywords
> property set against a binary file.
> >In general, be very careful about which files you ask Subversion to
> >munge. Don't do something like use the auto-props feature to
> >automatically set the text-munging properties on '*'. That's just
> >dangerous. Be specific instead: munge only specific file types.
> I took you at your word and believed that propset wouldn't set the
> keywords property on a binary file. Even above you say it shouldn't,
> but in the same breath backtrack. Obviously it didn't work as you
Well, Ben didn't quite backtrack; there are just different sequences
of steps possible. Some of them, the client will protect against;
others it won't, as we have now learned, hence Blair filed bug #2309.
I was just talking this over with Ben, and he had a very nice way to
put it: "In comparison with CVS, the safety has gone up, but the
useability has gone down."
SVN is safer, in the sense that it will not munge your binary files
unless you explicitly tell it to.
Unfortunately, the effect of this "safety" is to tempt people into
marking huge swaths of their trees with properties that imply that
stuff is text -- either by mime-type or by keyword expansion. That's
what happened to you. You wanted keywords expanded 95% of the time.
You set it to happen on everything (assuming, fairly I admit, that
you'd be protected against binary files getting keyword expansion).
Then when SVN did exactly what you said, instead of what you wanted &
expected, you had a problem.
By the way, I'm not denying that your expectations were reasonable.
Once bug #2309 is fixed, life will be easier.
In the meantime, the workaround is to find all files with
svn:mime-type of "application/octet-stream", unset any svn:keywords
properties on them, and fix them if they're corrupted. Sorry, I know
that's not ideal, but it's what can be done right now.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri May 20 22:39:57 2005