On Mon, Sep 12, 2011 at 12:37 PM, Philip Martin
<philip.mar...@wandisco.com> wrote:
> Johan Corveleyn <jcor...@gmail.com> writes:
>
>> No, I don't think that's the problem. That should work (can't test
>> right now, being @work, but I don't see why it wouldn't work on
>> Windows). I think the OP means that the following doesn't work:
>>
>> # move foo FOO
>> # svn ci
>>
>> (i.e. doing the rename outside of svn)
>
> I know the rename is done outside svn, but the original post shows "svn
> rm" and an "svn add" after that. So it appears that
>
> # move foo FOO
> # svn rm foo
> # svn add FOO
> # svn ci
>
> doesn't work on Windows. The difference between this and the cases that
> are known to work is that in the above case FOO is added without any
> copyfrom.
Oh, sorry, I misread that part.
There might indeed be a problem, and I think it might be caused by the
fix for issue #3865 [1] ('svn' on Windows cannot address
scheduled-for-delete file, if another file differing only in case is
present on disk), which was needed to fully support case-only renames
for issue #3702.
For fixing #3865, we introduced some code to be able to make 'svn'
address items (1) which are no longer present on disk, (2) which are
still present in wc.db, and (3) for which another case-clashing file
*is* on disk. This was needed to be able to perform "svn commit foo
FOO", after doing the case-only rename with svn. Without the changes
for #3865, svn (on Windows) would always "case-normalize" its
arguments to whatever it finds on disk, so it would always think
you're talking about FOO.
I'm not sure how this relates precisely to this scenario (would have
to play around with it @home), but maybe there is a bug in that code,
or maybe it simply doesn't work with the current implementation. I'll
try to take a look tonight, but if you or anyone else gets there
first: the code for fixing issue #3865 was introduced in r1124469.
--
Johan
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=3865
