You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Justin Johnson <ju...@gmail.com> on 2012/01/27 17:00:22 UTC
svn status returns incorrect results on Windows 7
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.
Thanks.
Justin
Re: svn status returns incorrect results on Windows 7
Posted by Justin Johnson <ju...@gmail.com>.
On Tue, Jan 31, 2012 at 2:47 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Jan 31, 2012 at 3:35 AM, Justin Johnson
> <ju...@gmail.com> wrote:
>> On Sun, Jan 29, 2012 at 3:25 PM, Konstantin Kolinko
>> <kn...@gmail.com> wrote:
>>> 2012/1/27 Justin Johnson <ju...@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.
Re: svn status returns incorrect results on Windows 7
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Jan 31, 2012 at 3:35 AM, Justin Johnson
<ju...@gmail.com> wrote:
> On Sun, Jan 29, 2012 at 3:25 PM, Konstantin Kolinko
> <kn...@gmail.com> wrote:
>> 2012/1/27 Justin Johnson <ju...@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.
--
Johan
Re: svn status returns incorrect results on Windows 7
Posted by Justin Johnson <ju...@gmail.com>.
On Sun, Jan 29, 2012 at 3:25 PM, Konstantin Kolinko
<kn...@gmail.com> wrote:
> 2012/1/27 Justin Johnson <ju...@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?
Re: svn status returns incorrect results on Windows 7
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/1/27 Justin Johnson <ju...@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