You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Marc Strapetz <ma...@syntevo.com> on 2011/09/12 10:50:59 UTC
SVN 1.7 problems with case insensitive file systems (Windows)
There are some problems when capitalization of a file or directory name
changes in the working copy (at least on Windows). I'm starting off with
following tree:
# svn status -v
1 1 Marc .
1 1 Marc a
1 1 Marc a\mu
1 1 Marc a\b
1 1 Marc a\b\lambda
1 1 Marc a\b\e
1 1 Marc a\b\e\alpha
1 1 Marc a\b\e\beta
1 1 Marc a\d
1 1 Marc a\d\gamma
1 1 Marc iota
Then a/b/e will be changed to upper case a/b/E:
# svn status
! a\b\e
? a\b\E
This is somewhat strange as a/b/e is missing, but a/b/e/alpha and beta
are not. Adding the unversioned directory and removing the missing one
seems to work:
# svn add a/b/E
# svn rm a/b/e
# svn status
! a\b\E
! a\b\E\alpha
! a\b\E\beta
D a\b\e
D a\b\e\alpha
D a\b\e\beta
However, a subsequent commit fails:
# svn commit -m "a/b/e moved to a/b/E"
svn: E155010: Commit failed (details follow):
svn: E155010: 'D:\greek-tree.svn\a\b\E' is scheduled for addition, but
is missing
There are more unexpected results, when starting off with a modified
a/b/e/alpha:
# svn status
M a\b\e\alpha
# svn cat a\b\e\alpha
new file content
Again, a/b/e is changed to a/b/E. Then status is more or less OK:
# svn status
! a\b\e
M a\b\e\alpha
? a\b\E
When adding a\b\E now, alpha gets duplicated:
# svn add a\b\E
# svn status
! a\b\e
M a\b\e\alpha
A a\b\E
A a\b\E\alpha
A a\b\E\beta
Removing a\b\e doesn't work:
# svn rm a\b\e
svn: E195006: Use --force to override this restriction (local
modifications may be lost)
svn: E195006: 'D:\greek-tree.svn\a\b\e\alpha' has local modifications --
commit or revert them first
Committing seems to work:
# svn commit -m "a/b/e moved to a/b/E"
Adding a\b\E
Adding a\b\E\alpha
Adding a\b\E\beta
Sending a\b\e\alpha
Transmitting file data ...
Committed revision 2.
It has added a/b/E, as expected:
# svn ls file://localhost/d:/greek-tree.repo
a/
a/b/
a/b/E/
a/b/E/alpha
a/b/E/beta
a/b/e/
a/b/e/alpha
a/b/e/beta
a/b/lambda
a/d/
a/d/gamma
a/mu
iota
But it has modified a/b/e/alpha as well, unexpectedly:
# svn cat file://localhost/d:/greek-tree.repo/a/b/e/alpha
new file content
# svn cat file://localhost/d:/greek-tree.repo/a/b/E/alpha
new file content
Apart from a possible fix in 1.7 series (which I understand might be
quite complex), what would be the correct resp. expected behavior?
>From the perspective of a UI client, would you recommend to reject
working with case-changed entries at all to avoid mentioned problems?
Instead the user could be told to fix the file name case changes or the
client does that automatically (like TSVN does for SVN 1.6).
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Sep 13, 2011 at 1:32 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 2:17 PM, Philip Martin
> <ph...@wandisco.com> wrote:
>> Philip Martin <ph...@wandisco.com> writes:
>>
>>> and the commit failed compaining the a/b/E is missing. Now that commit
>>> works, on case-sensitive and case-insensitive filesystems, when the
>>> added tree is a mv with copyfrom. Marc's mail appears to show that it
>>> fails on Windows when the added tree is a plain add without copyfrom.
>>
>> No, I'm misreading. When Marc ran "svn rm" it appears to have marked
>> the missing tree as deleted, which is what we want, but also to have
>> removed the added tree from the disk. The tree remains added in wc.db
>> but is missing from disk, and that leads to the failed commit.
>
> Yes, I think that's more or less what happens.
>
> I tried Marc's scenario with a simple file on Windows, printing status
> after every step:
>
> [[[
> C:\research\svn\experiment\wc\test4\foo>move bar BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> ! bar
> ? BAR
> ### this is ok
>
> C:\research\svn\experiment\wc\test4\foo>svn add BAR
> A BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> ! bar
> A BAR
> ### this is ok
>
> C:\research\svn\experiment\wc\test4\foo>svn rm bar
> D bar
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> ! BAR
> D bar
> ### this is wrong
> ]]]
>
> It seems your analysis is correct, in that the last step, "svn rm
> bar", removes BAR from disk, causing the problem.
>
> Also, if "svn rm bar" is performed first, BAR also gets deleted from
> disk, and you can't even add it anymore:
>
> [[[
> C:\research\svn\experiment\wc\test4\foo>move bar BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> ! bar
> ? BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn rm bar
> D bar
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> D bar
>
> C:\research\svn\experiment\wc\test4\foo>svn add BAR
> svn: warning: W155010: 'C:\research\svn\experiment\wc\test4\foo\BAR' not found
> svn: E200009: Could not add all targets because some targets don't exist
>
> C:\research\svn\experiment\wc\test4\foo>dir /B
>
> ]]]
>
>
> However, it seems that adding --keep-local to the rm command is a
> workaround. It avoids the (wrong) local file to be deleted from disk:
>
> [[[
> C:\research\svn\experiment\wc\test4\foo>move bar BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> ! bar
> ? BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn add BAR
> A BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> ! bar
> A BAR
>
> C:\research\svn\experiment\wc\test4\foo>svn rm bar --keep-local
> D bar
>
> C:\research\svn\experiment\wc\test4\foo>svn st
> D bar
> A BAR
> ]]]
>
>
> I don't have time to dig deeper and figure out a solution, but I think
> the problem is that the "rm" command will eventually execute
> svn_io_remove_file2, which will try to delete "bar" from disk (through
> various APR and/or Windows API's). But on Windows, when you try to
> delete bar while there is a BAR on disk, it will simply delete BAR.
>
> That said, in general "svn rm bar" *should* remove BAR from disk (if
> there isn't a "bar" in wc.db), because "svn" also performs
> case-canonicalization for its arguments, analogous to other tools on
> Windows.
>
> But it shouldn't do that in this special case, where the user wants to
> act upon another (case-clashing, missing-from-disk) item in wc.db.
> This situation is discovered in cmdline.c, lines 285 and following --
> the fix for issue #3865. I have no idea how to transfer that knowledge
> from cmdline.c to a keep-local flag for the delete command or
> something like that ...
I have filed this as issue #4023 (on Windows, 'svn rm' incorrectly
deletes on-disk file if it is case-clashing with intended
(non-on-disk) target) [1].
I think it's more severe than I thought at first, because it can
result in the loss of an uncommitted file. And this situation couldn't
happen on 1.6 (except when using --force).
I don't think it's a blocker for 1.7 (but maybe others disagree?),
because it's a rather edge-case scenario. But we should try to fix
this sooner rather than later. I don't have the time available right
now to dig into this (and no idea how to solve this), but maybe one of
the other (Windows) devs can take a look?
@Philip: was there also some other issue in this thread? You pointed
out several (other) problems in your initial reply.
[1] http://subversion.tigris.org/issues/show_bug.cgi?id=4023
--
Johan
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Sep 12, 2011 at 2:17 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> and the commit failed compaining the a/b/E is missing. Now that commit
>> works, on case-sensitive and case-insensitive filesystems, when the
>> added tree is a mv with copyfrom. Marc's mail appears to show that it
>> fails on Windows when the added tree is a plain add without copyfrom.
>
> No, I'm misreading. When Marc ran "svn rm" it appears to have marked
> the missing tree as deleted, which is what we want, but also to have
> removed the added tree from the disk. The tree remains added in wc.db
> but is missing from disk, and that leads to the failed commit.
Yes, I think that's more or less what happens.
I tried Marc's scenario with a simple file on Windows, printing status
after every step:
[[[
C:\research\svn\experiment\wc\test4\foo>move bar BAR
C:\research\svn\experiment\wc\test4\foo>svn st
! bar
? BAR
### this is ok
C:\research\svn\experiment\wc\test4\foo>svn add BAR
A BAR
C:\research\svn\experiment\wc\test4\foo>svn st
! bar
A BAR
### this is ok
C:\research\svn\experiment\wc\test4\foo>svn rm bar
D bar
C:\research\svn\experiment\wc\test4\foo>svn st
! BAR
D bar
### this is wrong
]]]
It seems your analysis is correct, in that the last step, "svn rm
bar", removes BAR from disk, causing the problem.
Also, if "svn rm bar" is performed first, BAR also gets deleted from
disk, and you can't even add it anymore:
[[[
C:\research\svn\experiment\wc\test4\foo>move bar BAR
C:\research\svn\experiment\wc\test4\foo>svn st
! bar
? BAR
C:\research\svn\experiment\wc\test4\foo>svn rm bar
D bar
C:\research\svn\experiment\wc\test4\foo>svn st
D bar
C:\research\svn\experiment\wc\test4\foo>svn add BAR
svn: warning: W155010: 'C:\research\svn\experiment\wc\test4\foo\BAR' not found
svn: E200009: Could not add all targets because some targets don't exist
C:\research\svn\experiment\wc\test4\foo>dir /B
]]]
However, it seems that adding --keep-local to the rm command is a
workaround. It avoids the (wrong) local file to be deleted from disk:
[[[
C:\research\svn\experiment\wc\test4\foo>move bar BAR
C:\research\svn\experiment\wc\test4\foo>svn st
! bar
? BAR
C:\research\svn\experiment\wc\test4\foo>svn add BAR
A BAR
C:\research\svn\experiment\wc\test4\foo>svn st
! bar
A BAR
C:\research\svn\experiment\wc\test4\foo>svn rm bar --keep-local
D bar
C:\research\svn\experiment\wc\test4\foo>svn st
D bar
A BAR
]]]
I don't have time to dig deeper and figure out a solution, but I think
the problem is that the "rm" command will eventually execute
svn_io_remove_file2, which will try to delete "bar" from disk (through
various APR and/or Windows API's). But on Windows, when you try to
delete bar while there is a BAR on disk, it will simply delete BAR.
That said, in general "svn rm bar" *should* remove BAR from disk (if
there isn't a "bar" in wc.db), because "svn" also performs
case-canonicalization for its arguments, analogous to other tools on
Windows.
But it shouldn't do that in this special case, where the user wants to
act upon another (case-clashing, missing-from-disk) item in wc.db.
This situation is discovered in cmdline.c, lines 285 and following --
the fix for issue #3865. I have no idea how to transfer that knowledge
from cmdline.c to a keep-local flag for the delete command or
something like that ...
--
Johan
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> and the commit failed compaining the a/b/E is missing. Now that commit
> works, on case-sensitive and case-insensitive filesystems, when the
> added tree is a mv with copyfrom. Marc's mail appears to show that it
> fails on Windows when the added tree is a plain add without copyfrom.
No, I'm misreading. When Marc ran "svn rm" it appears to have marked
the missing tree as deleted, which is what we want, but also to have
removed the added tree from the disk. The tree remains added in wc.db
but is missing from disk, and that leads to the failed commit.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Philip Martin <ph...@wandisco.com>.
I don't think this is a problem with the command line processing
(although it may be a problem with my example, perhaps
# move foo foo_temp
# svn rm foo
# move foo_temp FOO
# svn add FOO
# svn ci
would work better).
However you achieve it, Marc's earlier mail showed the wc.db with a
deleted tree and an added tree with names that differ only in case:
sqlite> select local_relpath, op_depth, presence from nodes;
a|0|normal
a/b|0|normal
a/b/e|0|normal
a/b/e/alpha|0|normal
a/b/e/beta|0|normal
a/b/lambda|0|normal
a/d|0|normal
a/d/gamma|0|normal
a/mu|0|normal
iota|0|normal
|0|normal
a/b/E|3|normal
a/b/E/alpha|4|normal
a/b/E/beta|4|normal
a/b/e|3|base-deleted
a/b/e/alpha|3|base-deleted
a/b/e/beta|3|base-deleted
and the commit failed compaining the a/b/E is missing. Now that commit
works, on case-sensitive and case-insensitive filesystems, when the
added tree is a mv with copyfrom. Marc's mail appears to show that it
fails on Windows when the added tree is a plain add without copyfrom.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Sep 12, 2011 at 12:37 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Johan Corveleyn <jc...@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
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@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.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Sep 12, 2011 at 12:08 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Marc Strapetz <ma...@syntevo.com> writes:
>
>>>> Adding the unversioned directory and removing the missing one
>>>> seems to work:
>>>>
>>>> # svn add a/b/E
>>>> # svn rm a/b/e
>>>> # svn status
>>>> ! a\b\E
>>>> ! a\b\E\alpha
>>>> ! a\b\E\beta
>>>> D a\b\e
>>>> D a\b\e\alpha
>>>> D a\b\e\beta
>>>>
>>>> However, a subsequent commit fails:
>>>>
>>>> # svn commit -m "a/b/e moved to a/b/E"
>>>> svn: E155010: Commit failed (details follow):
>>>> svn: E155010: 'D:\greek-tree.svn\a\b\E' is scheduled for addition, but
>>>> is missing
>>>
>>> That's odd. It looks like a case-only rename and issue 3702 claims to
>>> be fixed:
>>>
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=3702
>>>
>>> If you start with a pristine, unmodified tree and run
>>>
>>> svn mv a\b\e a\b\E
>>>
>>> can you commit that?
>>
>> Yes, that works.
>
> So
>
> # svn mv foo FOO
> # svn ci
>
> works and I would assume that
>
> # svn rm foo
> # svn cp bar FOO
> # svn ci
>
> also works. But
>
> # svn rm foo
> # svn add FOO
> # svn ci
>
> doesn't work. Probably not been tested before on Windows. To me it
> looks like it should be possible to make the code handle that, but
> perhaps the case-rename stuff relies on the copyfrom flags.
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)
--
Johan
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Philip Martin <ph...@wandisco.com>.
Marc Strapetz <ma...@syntevo.com> writes:
>>> Adding the unversioned directory and removing the missing one
>>> seems to work:
>>>
>>> # svn add a/b/E
>>> # svn rm a/b/e
>>> # svn status
>>> ! a\b\E
>>> ! a\b\E\alpha
>>> ! a\b\E\beta
>>> D a\b\e
>>> D a\b\e\alpha
>>> D a\b\e\beta
>>>
>>> However, a subsequent commit fails:
>>>
>>> # svn commit -m "a/b/e moved to a/b/E"
>>> svn: E155010: Commit failed (details follow):
>>> svn: E155010: 'D:\greek-tree.svn\a\b\E' is scheduled for addition, but
>>> is missing
>>
>> That's odd. It looks like a case-only rename and issue 3702 claims to
>> be fixed:
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3702
>>
>> If you start with a pristine, unmodified tree and run
>>
>> svn mv a\b\e a\b\E
>>
>> can you commit that?
>
> Yes, that works.
So
# svn mv foo FOO
# svn ci
works and I would assume that
# svn rm foo
# svn cp bar FOO
# svn ci
also works. But
# svn rm foo
# svn add FOO
# svn ci
doesn't work. Probably not been tested before on Windows. To me it
looks like it should be possible to make the code handle that, but
perhaps the case-rename stuff relies on the copyfrom flags.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Marc Strapetz <ma...@syntevo.com>.
On 12.09.2011 11:15, Philip Martin wrote:
> Marc Strapetz <ma...@syntevo.com> writes:
>
>> There are some problems when capitalization of a file or directory name
>> changes in the working copy (at least on Windows). I'm starting off with
>> following tree:
>>
>> # svn status -v
>> 1 1 Marc .
>> 1 1 Marc a
>> 1 1 Marc a\mu
>> 1 1 Marc a\b
>> 1 1 Marc a\b\lambda
>> 1 1 Marc a\b\e
>> 1 1 Marc a\b\e\alpha
>> 1 1 Marc a\b\e\beta
>> 1 1 Marc a\d
>> 1 1 Marc a\d\gamma
>> 1 1 Marc iota
>>
>> Then a/b/e will be changed to upper case a/b/E:
>>
>> # svn status
>> ! a\b\e
>> ? a\b\E
>>
>> This is somewhat strange as a/b/e is missing, but a/b/e/alpha and beta
>> are not.
>
> There is an assumption in the code that when a directory is missing the
> whole tree is missing, so that is the expected behaviour.
I can't confirm that. If I'm starting off with a clean working copy
(without having a/b/e changed its case) and I'm removing a/b/e, I'll get:
# svn status
! a\b\e
! a\b\e\alpha
! a\b\e\beta
>> Adding the unversioned directory and removing the missing one
>> seems to work:
>>
>> # svn add a/b/E
>> # svn rm a/b/e
>> # svn status
>> ! a\b\E
>> ! a\b\E\alpha
>> ! a\b\E\beta
>> D a\b\e
>> D a\b\e\alpha
>> D a\b\e\beta
>>
>> However, a subsequent commit fails:
>>
>> # svn commit -m "a/b/e moved to a/b/E"
>> svn: E155010: Commit failed (details follow):
>> svn: E155010: 'D:\greek-tree.svn\a\b\E' is scheduled for addition, but
>> is missing
>
> That's odd. It looks like a case-only rename and issue 3702 claims to
> be fixed:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3702
>
> If you start with a pristine, unmodified tree and run
>
> svn mv a\b\e a\b\E
>
> can you commit that?
Yes, that works.
>> When adding a\b\E now, alpha gets duplicated:
>>
>> # svn add a\b\E
>> # svn status
>> ! a\b\e
>> M a\b\e\alpha
>> A a\b\E
>> A a\b\E\alpha
>> A a\b\E\beta
>>
>> Removing a\b\e doesn't work:
>>
>> # svn rm a\b\e
>> svn: E195006: Use --force to override this restriction (local
>> modifications may be lost)
>> svn: E195006: 'D:\greek-tree.svn\a\b\e\alpha' has local modifications --
>> commit or revert them first
>
> Does adding force work?
Yes, that works.
# svn status
! a\b\E
! a\b\E\alpha
! a\b\E\beta
D a\b\e
D a\b\e\alpha
D a\b\e\beta
However commit fails with similar error message as before:
# svn commit -m "a b/e removed to a/b/E"
svn: E155010: Commit failed (details follow):
svn: E155010: 'D:\greek-tree\a
\b\E' is scheduled for addition, but is missing
That's the contents of wc.db after "svn rm -f":
sqlite> select local_relpath, op_depth, presence from nodes;
a|0|normal
a/b|0|normal
a/b/e|0|normal
a/b/e/alpha|0|normal
a/b/e/beta|0|normal
a/b/lambda|0|normal
a/d|0|normal
a/d/gamma|0|normal
a/mu|0|normal
iota|0|normal
|0|normal
a/b/E|3|normal
a/b/E/alpha|4|normal
a/b/E/beta|4|normal
a/b/e|3|base-deleted
a/b/e/alpha|3|base-deleted
a/b/e/beta|3|base-deleted
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Philip Martin <ph...@wandisco.com>.
Marc Strapetz <ma...@syntevo.com> writes:
> There are some problems when capitalization of a file or directory name
> changes in the working copy (at least on Windows). I'm starting off with
> following tree:
>
> # svn status -v
> 1 1 Marc .
> 1 1 Marc a
> 1 1 Marc a\mu
> 1 1 Marc a\b
> 1 1 Marc a\b\lambda
> 1 1 Marc a\b\e
> 1 1 Marc a\b\e\alpha
> 1 1 Marc a\b\e\beta
> 1 1 Marc a\d
> 1 1 Marc a\d\gamma
> 1 1 Marc iota
>
> Then a/b/e will be changed to upper case a/b/E:
>
> # svn status
> ! a\b\e
> ? a\b\E
>
> This is somewhat strange as a/b/e is missing, but a/b/e/alpha and beta
> are not.
There is an assumption in the code that when a directory is missing the
whole tree is missing, so that is the expected behaviour.
> Adding the unversioned directory and removing the missing one
> seems to work:
>
> # svn add a/b/E
> # svn rm a/b/e
> # svn status
> ! a\b\E
> ! a\b\E\alpha
> ! a\b\E\beta
> D a\b\e
> D a\b\e\alpha
> D a\b\e\beta
>
> However, a subsequent commit fails:
>
> # svn commit -m "a/b/e moved to a/b/E"
> svn: E155010: Commit failed (details follow):
> svn: E155010: 'D:\greek-tree.svn\a\b\E' is scheduled for addition, but
> is missing
That's odd. It looks like a case-only rename and issue 3702 claims to
be fixed:
http://subversion.tigris.org/issues/show_bug.cgi?id=3702
If you start with a pristine, unmodified tree and run
svn mv a\b\e a\b\E
can you commit that?
> There are more unexpected results, when starting off with a modified
> a/b/e/alpha:
>
> # svn status
> M a\b\e\alpha
>
> # svn cat a\b\e\alpha
> new file content
>
> Again, a/b/e is changed to a/b/E. Then status is more or less OK:
>
> # svn status
> ! a\b\e
> M a\b\e\alpha
> ? a\b\E
That looks like a bug. There is an assumption in the code that if a
directory is missing then it's children are missing as well (that's why
the earlier status didn't report alpha and beta as missing). Until now
it hasn't really made sense for a/b/e/alpha to be modified when a/b/e is
missing, so the code has never been written to handle it explicitly.
When that does happen the behaviour we have is accidental.
> When adding a\b\E now, alpha gets duplicated:
>
> # svn add a\b\E
> # svn status
> ! a\b\e
> M a\b\e\alpha
> A a\b\E
> A a\b\E\alpha
> A a\b\E\beta
>
> Removing a\b\e doesn't work:
>
> # svn rm a\b\e
> svn: E195006: Use --force to override this restriction (local
> modifications may be lost)
> svn: E195006: 'D:\greek-tree.svn\a\b\e\alpha' has local modifications --
> commit or revert them first
Does adding force work?
> Committing seems to work:
>
> # svn commit -m "a/b/e moved to a/b/E"
> Adding a\b\E
> Adding a\b\E\alpha
> Adding a\b\E\beta
> Sending a\b\e\alpha
> Transmitting file data ...
> Committed revision 2.
>
> It has added a/b/E, as expected:
>
> # svn ls file://localhost/d:/greek-tree.repo
> a/
> a/b/
> a/b/E/
> a/b/E/alpha
> a/b/E/beta
> a/b/e/
> a/b/e/alpha
> a/b/e/beta
> a/b/lambda
> a/d/
> a/d/gamma
> a/mu
> iota
>
> But it has modified a/b/e/alpha as well, unexpectedly:
>
> # svn cat file://localhost/d:/greek-tree.repo/a/b/e/alpha
> new file content
>
> # svn cat file://localhost/d:/greek-tree.repo/a/b/E/alpha
> new file content
That's probably a bug, it sort of follows on from the missing directory
having children that are present. It's not something that can happen on
a case-sensitive filesystem so the behaviour of the code is really just
accidental.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: SVN 1.7 problems with case insensitive file systems (Windows)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Sep 12, 2011 at 10:50 AM, Marc Strapetz
<ma...@syntevo.com> wrote:
> There are some problems when capitalization of a file or directory name
> changes in the working copy (at least on Windows). I'm starting off with
> following tree:
>
> # svn status -v
> 1 1 Marc .
> 1 1 Marc a
> 1 1 Marc a\mu
> 1 1 Marc a\b
> 1 1 Marc a\b\lambda
> 1 1 Marc a\b\e
> 1 1 Marc a\b\e\alpha
> 1 1 Marc a\b\e\beta
> 1 1 Marc a\d
> 1 1 Marc a\d\gamma
> 1 1 Marc iota
>
> Then a/b/e will be changed to upper case a/b/E:
>
> # svn status
> ! a\b\e
> ? a\b\E
Wait, how did a/b/e change to a/b/E?
- Renamed without telling svn? (i.e. renamed in Windows explorer, or
with the 'move' command from Windows). In this case, it's normal that
it doesn't work. You shouldn't do that. See also
http://subversion.apache.org/faq.html#wc-change-detection.
- Renamed through svn (i.e. 'svn move a/b/e a/b/E')? In this case, it
should work, and 'svn status' should show:
A + a\b\E
D a\b\e
[ Also: this question belongs on the users-mailinglist, and not on
dev@, because it's about the usage of svn (and problems during usage),
rather than it's development. If you want to continue this discussion,
please move it to users@. ]
--
Johan