[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Re: "Revision" case-sensitive in svn:keywords

From: <kfogel_at_collab.net>
Date: 2005-02-08 04:56:41 CET

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.