Simon Large wrote:
> Joseph Galbraith wrote:
>
>>Jeremy Swigart wrote:
>>
>>>Ok, I've observed what may be a bug but I am unsure. The first time a
>>>few weeks ago I thought it was a fluke, but yesterday it happens
>>>again.
>>>
>>>It seems that if a user renames a file, and simply changes the case
>>>of the filename, not change the filename itself, for example
>>>mycpp.cpp rename to MyCpp.cpp, it works fine on that persons
>>>computer, but it causes odd errors on other clients when they
>>>attempt to update.
>>
>>I believe I've seen this as well; it causes the update to
>>fail with 'entry already exists' or something like that.
>
>
> ... and you both need to read the manual, or the FAQ.
>
> http://tortoisesvn.berlios.de/faq/index.php?action=artikel&cat=7&id=34&artlang=en
>
> Remember that a subversion repository can be read by clients on
> case-sensitive file systems as well as by Windows clients. Subversion
> has to preserve the case, otherwise Linux and other clients could end up
> with multiple copies of a file, all differing only in case.
>
> Maybe it could be handled better, but if you want to complain you need
> to do that on the Subversion user list.
And I did note that it was probably a SVN issue.
(I have cc'd the subversion list now, because I hit on
something that might, or might not, help the situation.
Followups, if any should probably go there exclusively.)
However, just to make things clear, I'm not complaining.
I was merely noting that I too had seen the behavior, and
how I resolved the problem.
I certainly would not have been at all surprised to see
an error if someone had added a second file differing
case... I'm all too aware of the deficencies of the
Win32 API.
I will note, that, though it might be difficult
(I don't know, and won't guess, how difficult in SVN),
it is definitely possible to have a rename operation
where only the case of a file name changes work on a
case insensitive filesystem.
SVN would have to not assuming that the source and target
of a rename operation can exist simultaneously.
(Mind you this isn't a bug in SVN, just a limatation
that affects portability.)
Now that I've thought about it, it probably requires that
SVN understand renames as renames (a roadmap feature),
and the current assumption actually comes because
renames aren't renames, but rather copy / deletes.
Better behavior _might_ be obtained by reversing the
operation in SVN, if that is possible: delete the old
file first, and then copy it from the revision where
it previously existed. (I believe this is how I dealt
with rename operations when I was working on a source
safe converter.)
I can't say for sure, but this might result
in the update removing the old file first,
which would solve the problem.
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 20 19:02:04 2005