2012/2/3 Peter Samuelson <peter_at_p12n.org>:
>> On 02.02.2012 20:22, Peter Samuelson wrote:
>> > By proposing a client-only solution, I hope to avoid _all_ those
>> > questions.
> [Branko Cibej]
>> Can't see how that works, unless you either make the client-side
>> solution optional, create a mapping table, or make name lookup on the
>> server agnostic to character representation.
> Yes, I did propose a mapping table in wc.db.
> Old clients on OS X would continue to be confused; the solution is to
Until upgrading all clients, there are possibilities that NFD filenames
are checked in to repositories. So I proposed servers change filenames
to NFC before checking in to repositories.
But you gave me advice it is not good as a short term solution.
So I withdraw this part at this time. Please see my another post
( message id is
> New clients on OS X (and elsewhere) would maintain a mapping table
> between 'repository path' and 'local filesystem representation'. We
> already have these two concepts, given we support non-UTF-8 client
>> It would be nice if we could normalize paths in the repository
>> without having to perform a dump/reload cycle, but I don't know how
>> that would work in FSFS
> Indeed, it's a problem similar to obliterate, and carries the same risk
> of invalidating every wc. This is why I don't think it's a reasonable
> path to take in the short term (1.x).
Well, I don't understand here. Upgrading subversion client 1.6 to 1.7
did invalidated every wc, didn't it?
When I run 'svn info' with subversion 1.7 client on wc created by 1.6,
I see these message and cannot use it with 1.7.
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/your/wc/path/here' is too old (format 10,
created by Subversion 1.6)
)Hiroaki Nakamura) hnakamur_at_gmail.com
Received on 2012-02-02 22:59:42 CET