2012/1/30 Stefan Sperling <s...@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) hnaka...@gmail.com