On Mar 24, 2009, at 04:40, Sergio Lopes wrote:
>> What happens when you try?
> On the problematic file, svn complains that a file with the same name
> already exists, any checkout or update stops and I get half the code.
> After that, given that I have a incomplete working copy, I can't do
> much with svn.
> Also it seems I'm the only one having problems, the other programmers,
> using TortoiseSVN on Windows, have no issues with updating, committing
> or even checking the code.
Ok. Probably what has happened is you have committed two files to the
repository whose names contain the same UTF-8 characters but in one
case the characters are represented in composed form and in the other
case they are represented in decomposed form. Linux and Windows by
default create names in composed form, while Mac OS X creates names
in decomposed form. Linux and Windows will happily use files of
either representation. If you have both in your repository, they will
have no problem checking this out and showing you two different files
that appear to have the same name. Pretty confusing. Mac OS X will
attempt to convert both of these to the same (decomposed)
representation, but fail on the second one because the file of the
same name already exists.
You can use "svn ls" on the URL of the directory in question to
verify this. You should then use "svn cat" on the two files to
determine which one you want to keep, and "svn rm" the other one.
>> Have you run "svnadmin verify" on your repository? What does it say?
> All versions are properly verified, no errors found. As I indicated
> above, it breaks down to being only a problem with my machine, not the
> repository, as I feared.
Ok. Then there is nothing wrong (nothing corrupted, anyway) in your
>> Usually you would just set LANG to the correct value for your
>> system. For
>> example, on my Mac, I set LANG=en_US.UTF-8. I would think you
>> would want
>> that set for all programs; I don't see why it should be Subversion-
> I'm quite knew to this mac thing, and the all "if it ain't broken,
> don't fix it" idea keeps popping to me :). Everything works correctly
> in my system, or so it seems, even the terminal works fine in all
> other usages, so I changed only that setting.
>> Note that I'm on Tiger. On Leopard, I believe you can have the
>> Terminal set
>> LANG automatically for you. Look around in the preferences and window
> I can only find options to set the available encodings, and those are
> UTF-8 and the ISO-8859-1 and ISO-8859-9, as far as I can see, I have
> no option to tell the Terminal which is the default or used one.
Well there's probably no harm in setting the variable yourself
instead of having Terminal do it for you automatically.
> Funny enough, I was using SmartSVN, and only after ditching it did I
> found the encoding problem, SmartSVN never had any problems with the
> files, and it doesn't even sees the dual status for the same file, if
> only it was a decent client I would have been unaware of all this.
I haven't used SmartSVN. I cannot explain why it would not suffer
from the problem.
> Thanks for the information, I'll probably create the pre-commit hook
> nevertheless, and at least prevent future situations like this one,
> and as soon as I have the time, I'll look into the patch, though I
> don't really like to use such solution.
What would you have your pre-commit hook do? The only workable thing
I could think to have it do would be to only accept filenames in
decomposed UTF-8 representation and deny filenames in composed UTF-8
representation. This would mean anytime you want to create a new file
with UTF-8 characters, you would have to do so from a Mac (since
that's the only platform that creates decomposed UTF-8 filenames).
And that's probably inconvenient for your non-Mac-using coworkers.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-25 04:34:10 CET