On 08.12.2013 12:26, Thomas Åkesson wrote: > > >> >>> E.g. the issue raised by Bert 2013-11-24 regarding mergeinfo is not a >>> problem with n-p (I guess without thinking too much about it). >> >> Mergeinfo really has all the same problems as paths; in both cases, >> both the server and the client have to be normalization-agnostic and >> -preserving in all their path and mergeinfo operations. > > Wouldn't n-p be sufficient? Which incidentally is the default/legacy > behaviour. > > Mergeinfo should reference paths with the exact path of the > file/folder, I suppose. Do you expect to find legacy data where > mergeinfo contains paths that are not byte-equal to the repository paths?
I expect to find clients construct names with different character representation than exists in the mergeinfo. Just as they do with paths; the cases are exactly parallel. And yes, I wouldn't be surprised, given how we treat and generate mergeinfo, if there are repositories out there that have mergeinfo entries encoded differently than the paths they refer to. I don't expect them to be very common. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
