--
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!
Branko Èibej <brane@xbc.nu> wrote on 05/24/2005 05:56:31 AM:
> Blair Zajac wrote:
>
> > Ben Collins-Sussman wrote:
> >
> >>
> >> It's already the case that if svn:mime-type is set to a binary type,
> >> then 'svn propset' will refuse to set the svn:eol-style or
> >> svn:keywords properties. But apparently there are other ways to get
> >> them to co-exist... I suspect that the svn:mime-type is set *after*
> >> the text-munging ones, then you can end up with all three properties
> >> set at once. So if there's a bug here to report, it's perhaps that
> >> we aren't doing enough to prevent foot-shooting. :-)
> >
> >
> > I filed an issue
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=2309
> >
> > There's a script there that will reproduce this problem with one
> > commit setting svn:mime-type and a following commit setting
svn:keywords.
>
> This is *not* a bug. Subversion is working as designed.
>
> It has always been the policy on Subversion to have safe defaults, but
> not to restrict flexibility. Setting svn:keywords on "binary" files is a
> valid use case, because "binary" and "fixed-length records" are not
> synonyms. As far as Subversion is concerned, "binary" only means
> non-mergeable, it doesn't mean you shouldn't expand keywords. That's one
> of the reasons we have a separate svn:keywords property.
In all of the years that I have dealt with code, never have I run into
a situation where a keyword in a binary file should be
expanded/modified/whatever. Every binary file, whatever your
definition, I've ever worked with should never be modified, under any
circumstance.
With CVS, it was extremely easy to create a list of files that the -kb
flag would automatically be applied to, which therefore meant that
keyword subsitution would not take place.
With SVN, there isn't a master config file for a repository. So, we
are left with having to write hook scripts to correctly apply the
svn:keywords to files we want and to look for binary files and make
sure that the property isn't applied, due to user error. I wouldn't
call SVN safer when a user can screw it up.
Ben created the following quote: "In comparison with CVS, the safety
has gone up, but the useability has gone down."
Usability has definately gone down. And, as mentioned above, I don't
think safety has gone up when a user can cause keyword expansion on a
binary file, even if by mistake. I now have to write hooks in order
to parse what is being added to the repository to make sure that
svn:keywords is set for those files that should have it and make sure
that it isn't set for binary files. I should also check to make sure
that someone isn't changing the setting for file that should be set
or not set. Since I am new to SVN, I have a lot to learn about
hook script writing and no time to do it in :-(
OK, so it is doing exactly as designed. I have to disagree with the
notion that what is currently being done is right.
If there was a respository master config file, then an option can be
created that allows the administrator to create a list of file types
that can't have a list of properties attached to. For example, all
binary files can be marked as not being able to have the svn:keywords
property set.
If a site wants the ability to set that property against binary files,
then the master config file wouldn't contain that exception rule.
We DO NOT want users setting these properties. We want it transparent
to them. This kind of property setting can be done automatically, but
SVN doesn't allow that to easily happen. Users screw up constantly.
Give them the rope and they will hang themselves and I have to end up
fixing it.
So please, carefully consider our situation, which I suspect does not
just pertain to us.
MB
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 24 18:40:38 2005