2012/1/30 Stefan Sperling <stsp_at_elego.de>:
> I think the following caveats would be acceptable if they help
> with fixing the issue:
>
> - An upgrade path which optionally requires people to check all
> working copies out again, when either the server or the client is upgraded.
> Note again, this must be _optional_. Only people affected by the issue
> should have to make this choice, e.g. by changing configuration
> parameters from the default settings. By default, existing working
> copies should keep working after upgrading the client or server.
> Because imagine what would happen if an upgrade of the server broke
> many working copies checked out from a hosting service such as
> sourceforge.net -- not good.
>
> - An upgrade path which requires everyone to run 'svn upgrade' on their
> working copies in order to use the new client version, but not the
> new server version.
>
> - An upgrade path which requires people to dump/load their existing
> repositories in order to get rid of the problem. Existing
> repositories which are left alone should keep working as they do
> today, with problems on Mac OS X clients but no problems on other
> clients (anything else would cause too much breakage and confusion).
> E.g. this step could normalise all paths in all revisions. But keep in
> mind the problem of name collisions which can happen when the same name
> exists as both NFC and NFD. Something needs to happen in this case to
> resolve the problem, ideally giving users a choice about how to proceed.
How about adding a config per repository for unicode-normalization?
Possible config values are
- none: input paths are not normalized.
- NFC: input paths are normalized to NFC.
- NFD: input paths are normalized to NFD.
For compatibility, repositories which don't have this config are treated as
'none' specified.
Clients have to look this config and will normalize paths appropriately.
--
)Hiroaki Nakamura) hnakamur_at_gmail.com
Received on 2012-02-08 16:20:47 CET