Marc Strapetz <marc.strapetz_at_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
Received on 2011-09-12 11:15:55 CEST