On Fri, Jun 21, 2013 at 12:56 AM, Geoff Hoffman
<ghoffman_at_cardinalpath.com> wrote:
> Yes, that helps, Dave, thanks.
>
> But,
>
> deleting the file from Subversion, then adding the copy with the correct
> case.
>
> Question: Doesn't that blow away revision history? If I didn't care about
> revision history I would just start over with a fresh repo.
>
> I also thought about doing full URL svn mv's but seemed like that could take
> a very long time to do...
>
Why would that be slow? A server-side move is very quick, the files
themselves are not transferred over the network, ...
This is still a good workaround for executing case-only renames when
it doesn't work in the working copy. The only problem is that you
often want to combine the rename with refactoring of related source
code (referencing the file-to-be-renamed). And that's of course not
possible when doing just a server-side rename.
> On Thu, Jun 20, 2013 at 3:45 PM, Dave Huang <khym_at_azeotrope.org> wrote:
...
>> (Interesting/surprising that SVN 1.7 only fixed svn rename on Windows, but
>> not on other OSes with case-insensitive filesystems like MacOS X)
The reason for this is that APR (the Apache Portable Runtime [1], a
library svn heavily depends on for making platform specific behavior
generically accessible) does not have the required plumbing for MacOS
X.
I'm talking about the so called "truename" functionality, which, given
a filepath in a certain casing, returns the actual filepath in it's
correct on-disk casing (if present). This is implemented in APR for
Windows, but not for MacOS.
Why not? Simply because no-one has stepped up to do it. As soon as APR
supports this feature on MacOS, Subversion will be able to add support
for case-only renames on case-insensitive filesystems on MacOS.
I'm sure the nice APR folks would welcome constructive people who want
to work on this (and other things), so patches welcome I suppose :-)
...
[1] http://apr.apache.org/
--
Johan
Received on 2013-06-22 01:04:24 CEST