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
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