[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-23 20:42:08 CEST

See below for my response. BTW, found the Lotus Bloats way to add the ">"
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!

kfogel@newton.ch.collab.net wrote on 05/20/2005 03:01:41 PM:

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

Yep, the bug report will definately help. In the meantime I'll have to
create a hook script. All of this was discussed in my previous e-mail,
so I won't hash that again.

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

I love the quote. :-)

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

That is very good way of stating the situation.

> By the way, I'm not denying that your expectations were reasonable.
> Once bug #2309 is fixed, life will be easier.

And it should change Ben's quote as well :-) :-)

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

That is what I'll be doing.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 23 20:46:01 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.