Branko Čibej <brane@xbc.nu> writes:
> Proposal: When converting log messages to UTF-8, also convert line
> endings to LF. Conversely, when converting log messages to the
> locale encoding (for $EDITOR or for display purposes), also convert
> line endings to the native form.
>
> I think some of the special properties should get similar treatment:
>
> * Line-based textual properties: svn:ignore, svn:externals
> * Whitespace-separated textual properties: svn:keywords
>
> While we're at it, perhaps we should also strip all whitespace from
> keyword-like properties: svn:eol-style and svn:mime-type. I seem to
> recall that we already had problem reports because a newline found its
> way into svn:mime-type.
+1 on all of this.
> I think that leaves svn:executable, which I don't care about so
> much. It might make sense to only allow empty contents on that prop
> since it's a boolean -- only its existence matters, not the contents
> -- but that's more an aesthetic than a usability issue.
Hmmm. It's awkward for people to actually set empty contents -- in
many environments, they'll be forced to use quotes. Aesthetically and
intuitively, the first of these seems much better to me:
svn propset svn:executable on foo.sh
versus
svn propset svn:executable '' foo.sh
Although that does leave the possibility of someone trying
svn propset svn:executable off foo.sh
and being surprised when the file is still executable :-(. Not sure
what to do about that. We could check for counter-intuitive values,
but even then we'd never get all languages, just English and whatever
else some developer happened to take care of.
If we're going to allow just one value at propset time, rejecting all
others, maybe we should just go with English "on", and continue to
treat any non-null value as we do now? At least not the empty string,
that's going to be something people have to look up all the time.
Thoughts?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 6 19:54:51 2002