On Tue, Jan 31, 2012 at 2:47 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Tue, Jan 31, 2012 at 3:35 AM, Justin Johnson > <justinandto...@gmail.com> wrote: >> On Sun, Jan 29, 2012 at 3:25 PM, Konstantin Kolinko >> <knst.koli...@gmail.com> wrote: >>> 2012/1/27 Justin Johnson <justinandto...@gmail.com>: >>>> Hi, >>>> >>>> I am running Subversion 1.7.2 64 bit installer from CollabNet on >>>> Windows 7. The problem I'm experiencing can be seen in the output >>>> below. In summary, svn status is returning incorrect results, >>>> sometimes not showing that something has been modified and sometimes >>>> not recognizing that I'm in a working copy. This happens for me no >>>> matter how many times I recreate the working copy, and it happens if I >>>> store the working copy in C:\Users... as below or in C:\work. I do >>>> not have the same problem when trying to reproduce the problem with >>>> svn 1.7.2 on Solaris. >>>> >>>> PS C:\Users\myuser\wc> svn st >>>> M a\b\file.txt >>>> PS C:\Users\myuser\wc> cd a >>>> PS C:\Users\myuser\wc\a> svn st >>>> PS C:\Users\myuser\wc\a> cd b >>>> PS C:\Users\myuser\wc\a\b> svn st >>>> svn: warning: W155007: '.' is not a working copy >>>> >>>> Does anyone know why this is happening? I searched for this problem >>>> and only found TortoiseSVN users complaining about it, and some >>>> suggestions to make sure the user has full control of the filesystem. >>>> I did this without resolution, but decided to post here since it is a >>>> Subversion issue (with Windows 7 perhaps) and not a TortoiseSVN issue. >>>> >>> >>> It can happen because of wrong capitalization in the path. >>> >>> Are "a" and "b" real names? Are you able to reproduce this with the >>> Greek tree (repro-template.bat) [1]? Did you do the checkout with >>> command-line client or with Tortoise? >>> >>> >>> AFAIK, Tortoise 1.7.3+ does some additional work to normalize paths >>> before passing them to Subversion library methods. (TSVN issue 156. >>> There was notorious bug in that code - issue 169. Fixed in TSVN 1.7.4 >>> [2]). >>> >>> In my experience Windows command shell also does some normalization >>> when I do "cd" command. >>> >>> >>> [1] >>> http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs >>> [2] http://code.google.com/p/tortoisesvn/issues/detail?id=156 >>> http://code.google.com/p/tortoisesvn/issues/detail?id=169 >>> >>> Best regards, >>> Konstantin Kolinko >> >> Thank you so much for the reply. It *does* have to do with >> capitalization. I never would have guessed that. If I cd into >> directories and always use the correct case, the commands work fine >> every time. If I cd into a path using the incorrect case, I of course >> am able to cd but then svn doesn't return the correct results. >> >> Does anyone know if there are plans to fix this behavour in Subversion >> as opposed to working around them in TortoiseSVN? > > It's not clear to me whether this is a problem in Subversion core (in > which case TSVN now has a good workaround, but it should really be > fixed in SVN), or TSVN calling the API in an incorrect way (in which > case the only fix is in TSVN --- it could also still be a "bug" in the > specs of the API of course). > > Maybe this is the same issue as the one reported here: > > http://svn.haxx.se/dev/archive-2012-01/0247.shtml > > AFAIK, Bert Huijben was looking into that, but I'm not sure whether > he's close to fixing it. >
I get the problem using the svn that comes with the CollabNet Subversion installer, so it is definitely a core svn problem and not TortoiseSVN.
