[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SVN 1.7 problems with case insensitive file systems (Windows)

From: Marc Strapetz <marc.strapetz_at_syntevo.com>
Date: Mon, 12 Sep 2011 10:50:59 +0200

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

# 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

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
Received on 2011-09-12 10:52:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.