kfogel@collab.net wrote:
> 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.
I'd be happy with just canonicalizing the input - for example, you can set
svn:executable to any value, and it is silently canonicalized. I would apply
the same logic to svn:keywords, and fully canonicalize the values -
including the whitespace, particular alias, and order, too.
Essentially, parse the keywords value (permissively) and then rewrite the
string from the parsed set of booleans.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 8 12:17:05 2005