On Thu, Feb 09, 2012 at 12:20:14AM +0900, Hiroaki Nakamura wrote:
> 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.
Let's see how this fits the above contraints.
- Backwards compatible by default?
=> Yes, no dump/load or re-checkout required during a normal upgrade
- Repository can be used by old clients after changing config to
NFC/NFD?
=> Yes, but the server will reject commits using non-normalised
paths. This is no different to installing a pre-commit hook
that performs this check, so that should be OK. Users of old
clients must manually make sure that names are normalised.
- Need to dump/load repository to fix the problem for all revisions?
=> Yes
- Need to re-checkout existing working copies of the repository?
=> Yes, but only if config is changed from the default.
So I think this looks fine from the backwards compatibility standpoint.
Open questions:
- How can the client retrieve the configuration from the server?
This is related to server-dictated configuration, see
http://wiki.apache.org/subversion/ServerDictatedConfiguration
and http://subversion.tigris.org/issues/show_bug.cgi?id=1974
This issue would need to be solved first.
- What happens if NFC/NFD is enabled in repository config, but the
repository contains non-normalised paths (i.e. did not go through
a dump/load cycle to normalise all paths)?
- How do we handle name collisions if both NFC and NFD forms exist
in a repository that sets the configuration to NCF or NFD?
Is an upgrade not supported in this case?
Or will duplicate paths need to be discarded from history?
How can the user filter the paths, and how can the user decide
which path is kept?
Or will duplicate paths be renamed throughout history?
How can the user rename the paths?
Anything else? I cannot think of more questions but there might
be more things to consider here.
Received on 2012-02-08 17:19:46 CET