Marc Strapetz <marc.strap...@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
