Have we already considered the possibility of disallowing the
case-insensitive versions at propset/propedit time, starting now,
while continuing to respond to them in expansion?
I don't recall seeing that proposal on this thread, but it might solve
most of the problem here...
To be completely precise, what I'm proposing is:
1) Any words in an svn:keywords value that currently cause keyword
expansion to happen, would continue to do so. This includes
words that are case-variants of keywords (keywords which are
themselves case-sensitive in the working file, of course).
2) At propset/propedit time, check the value of svn:keywords,
disallowing case-variants -- all new incoming svn:keywords
values would have to match the real keyword case.
This would mean that if you have a legacy svn:keywords property:
"author date id"
and you attempt set/edit it to:
"author date id Revision"
... there would be an error saying that all the keywords must match
with exact case now. I'm not bothering to come up with the exact
wording of that error right now, but maybe it could clarify the
historical reasons behind the new behavior.
-Karl
John Peacock <jpeacock@rowman.com> writes:
> 1) The keyword strings inside the files are currently case-sensitive
> (and I personally see no reason to change that now or ever).
>
> 2) The capitalization of the svn:keywords should match the actual
> keywords as appear in the file, for consistencies sake. There is no
> benefit to having the svn:keywords _not_ be case-sensitive (and it may
> even cause people to request breaking #1 for their
> laziness^Wconvenience).
>
> 3) We cannot take back the short versions being case-insensitive until
> a major release (at which point we could fix up the existing
> svn:keywords entries in the nigh inevitable dump/load cycle).
>
> 4) The case-insensitivity of the short versions is _not documented_
> anywhere (indeed the subject isn't covered at all in the book and it
> is only through experimentation that the user discovers that it _is_
> case-sensitive in the WC file).
>
> 5) Making all of the svn:keywords entries case-insensitive and then
> _documenting_ that removes a minor programmer visible inconsistency,
> but doesn't improve the experience for the user one iota, since they
> /still/ have to remember that inside the file all keywords _are_
> case-sensitive.
>
> Therefore, I don't think the relatively minor gratification of making
> the interface internally consistent is worth possibly limiting our
> actions in future releases. As I said, I don't have enough voltage to
> actually veto this (and I can see your point, really I can), but if
> you (Max) do go ahead and do this, I would suggest that any patch
> include the documentation and spell out exactly what promise we are
> now going to keep /vis a vis/ keyword capitalization, both in
> svn:keywords and in the files themselves.
>
> John
>
> --
> John Peacock
> Director of Information Research and Technology
> Rowman & Littlefield Publishing Group
> 4720 Boston Way
> Lanham, MD 20706
> 301-459-3366 x.5010
> fax 301-429-5747
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 8 05:10:20 2005