Re: Proposed resolution: Standardizing on UTF-8 isn't enough

But couldn't it be possible right now, that there is a file in NFC *and* NFD
already in the repository? IMHO there needs to be some "tool" to verify/fix
the file names in the repository.

My opinion regarding your proposed solutions:
(1) this suggestion addresses the current problem, except for already
existing repositories with NFD (which should be easy to fix with the
repository-verification/fixing-tool)

(2) I don't understand yet, what problems can arise with this approach in
the future.

(3) seems to me a lightweight version of (1) which makes it more attractive
to me.

=> I recommend to standardize on one encoding, otherwise you don't know
exactly what problems might occur in the future. You can see on this
particular bug/issue what problems can occur when not standardizing.

--
Best regards,
Thomas Singer
_____________
SyntEvo GmbH
Brunnfeld 11
83404 Ainring
Germany
www.syntevo.com
Erik Huelsmann wrote:
> On 7/18/07, Thomas Singer <subversion@smartcvs.com> wrote:
>> Excellent analysis! Just one additional thought: how to handle old NFD 
>> file
>> names from old Mac clients when using a newer, NFC/NFD-aware server? Is
>> there a possibility to abort when an non-NFC/NFD-aware client version is
>> detected by the server side?
> 
> In a system which standardizes on NFC, but is generally NFC/NFD
> agnostic, old clients sending NFD encoded paths shouldn't be a
> problem. Nor should NFD paths in the repository, since the path will
> match the one in the other NF and the commit will be rejected. Or, it
> will proceed as planned when neither NF path exists.
> 
> The only reason to standardize on NFC would be not to move the NFC/NFD
> problem into the Windows/Unix domain where the filesystem treats paths
> as general byte sequences.
> 
> 
> Hope that explains it?
> 
> bye,
> 
> 
> Erik.
> PS: I contacted dev@apr re your other Mac problem with the locale
> thing; they tend to agree the current APR behaviour regarding Darwin
> filesystem encodings is incorrect and my proposal would improve the
> situation. I'll keep you posted.
> 
> ---------------------------------------------------------------------
> 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