On 21.07.2007 01:42, Daniel A. Steffen wrote:
> One cause for this behavior is the fact that the .svn/entries file
> stores utf8 filenames as present in the repository rather than in the
> working copy on disk.
> The two need not be identical, which is exactly what happens in the
> above situation: during checkout the file is created with the repository
> name, but the actual on disk name ends up being different (due to HFS
> filename normalization), causing a mismatch later on when that working
> copy filename is compared to the repository names stored in the entries
> file.
>
> A possible alternative approach to fix this problem could thus be to
> change the 'name' field of entries records to the working copy name, and
> to store the repository name in a new field (or possibly the existing
> 'url' field).
>
> This has the advantage that there is no need for subversion to
> know/implement how a given filesystem might transform filenames (i.e. no
> platform or ICU dependency etc), as that info can be obtained by
> creating a file with the name in question in an empty temp dir followed
> by listing of dir contents.
Right. Keepling a local 'matching table' between repository vs.
local file names could also be a solution for Windows users that are
busted with repositories containing file with the same name, once
lower case, once upper case. Then, one of these files could have a
slightly different local file name, and both could be checked out,
worked with etc.
Certainly, Any reference to such files (e.g., in Makefiles) would
not work if the local applications don't know when and how to
convert between the stored and local file name.
> I may well be overlooking something basic, but it seems to me that this
> approach would be simpler, more robust & less restrictive than the
> proposals involving normalization on some/all platforms and potential
> repository changes.
I agree, forcing any normalization is _not_ Subversion's job,
neither to NFC nor NFD. These should be client-level additions.
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 23 11:40:20 2007