Case sensitivity bug in windows with powershell.
I searched the reports database but could not find this error reported. Use a powershell shell and stand in the working copy: PS c:\temp\WC> svn mkdir APA PS c:\temp\WC> Set-LocationEx apa PS c:\temp\WC\apa>svn mkdir banan results in: svn: E15: Can't find parent directory's node while trying to add 'R:\products\PTI\ADAPTERS\SIRI\apa\banan' svn: E155010: The node 'R:\products\PTI\ADAPTERS\SIRI\apa' was not found. I don't really know how powershell/windows works when it comes to the current directory, but Get-Location will say you are in "apa" after the Set-LocationEx command, instead of the APA directory. This confuses users not familiar with other operating systems. /Sebastian
Re: Case sensitivity bug in windows with powershell.
On Mon, Nov 12, 2012 at 10:48 AM, Sebastian Andersson wrote: > I searched the reports database but could not find this error reported. > > Use a powershell shell and stand in the working copy: > PS c:\temp\WC> svn mkdir APA > PS c:\temp\WC> Set-LocationEx apa > PS c:\temp\WC\apa>svn mkdir banan > results in: > svn: E15: Can't find parent directory's node while trying to add > 'R:\products\PTI\ADAPTERS\SIRI\apa\banan' > svn: E155010: The node 'R:\products\PTI\ADAPTERS\SIRI\apa' was not found. > > I don't really know how powershell/windows works when it comes to the > current directory, but Get-Location will say you are in "apa" after > the Set-LocationEx command, instead of the APA directory. > > > This confuses users not familiar with other operating systems. For those that are not too familiar with powershell (like me): what does Set-LocationEx do? Does it do a rename of APA to apa (like the more usual Windows command 'move APA apa' does)? If so, then what you're seeing is normal. You're renaming the directory on the filesystem, outside of SVN. In SVN's metadata the directory is still known as APA, while on disk it's apa. SVN will then consider APA "missing" and apa "unversioned". You should do 'svn move APA apa' instead, if you want the move to be consistent between the filesystem and SVN's metadata. -- Johan
Re: Case sensitivity bug in windows with powershell.
On Mon, Nov 12, 2012 at 11:44 AM, Johan Corveleyn wrote: > For those that are not too familiar with powershell (like me): what > does Set-LocationEx do? > > Does it do a rename of APA to apa (like the more usual Windows command > 'move APA apa' does)? Sorry about that, I should have been more clear. No, it is "cd" in almost every other shell (and usually in powershell too via aliases). /Sebastian -- One laptop per child project: http://laptop.org/
Re: Case sensitivity bug in windows with powershell.
On Mon, Nov 12, 2012 at 11:54 AM, Sebastian Andersson wrote: > On Mon, Nov 12, 2012 at 11:44 AM, Johan Corveleyn wrote: >> For those that are not too familiar with powershell (like me): what >> does Set-LocationEx do? >> >> Does it do a rename of APA to apa (like the more usual Windows command >> 'move APA apa' does)? > > Sorry about that, I should have been more clear. No, it is "cd" in > almost every other shell (and usually in powershell too via aliases). Hm, I don't see this problem with "cd" in cmd.exe. The cd command does automatically use on the correct casing of the directory: [[[ C:\Temp\svntest>svn --version -q 1.7.7-SlikSvn-1.7.7-X64 C:\Temp\svntest>svnadmin create repos C:\Temp\svntest>svn co file:///C:/Temp/svntest/repos wc Checked out revision 0. C:\Temp\svntest>cd wc C:\Temp\svntest\wc>svn mkdir APA A APA C:\Temp\svntest\wc>cd apa C:\Temp\svntest\wc\APA>svn mkdir banan A banan ]]] You see that the last prompt correctly shows APA, the exact casing like it is on disk, even though I asked Windows to cd into apa. That looks like the correct behavior of Windows (case-insensitive, but case-preserving (so showing/using the known casing wherever it is used)). So IMO the problem is with the Set-LocationEx call that you do (or the Windows implementation thereof). It seems to me that Windows should be consistent and cd you into the correctly cased directory (whichever case you ask for). Alternatively, maybe Set-LocationEx is documented as showing this rather strange behavior (in that case, you should not use it, or you should make sure yourself that the case you ask for is correct before you call Set-LocationEx). -- Johan
Re: Case sensitivity bug in windows with powershell.
On Mon, Nov 12, 2012 at 1:13 PM, Johan Corveleyn wrote: > Hm, I don't see this problem with "cd" in cmd.exe. No, the problem is only with powershell, but I do believe powershell does what it is designed to do in this case. It uses a unified location system for more things than just filesystems (you can cd into the registry, LDAP etc) and some of them are case sensitive so it preserves the user's typed string. The problem is also with the Set-Location cmdlet, the old, default "cd" command in powershell. Powershell contributes to this problem a bit more; in powershell you can tab-expand the path names. If you just tab-expand one directory at a time, it changes to the correct case of it. But if you write two directories at once (ie apa\Banana), only the second directory gets changed into the correct case. With a longer path and a single letter with the incorrect case, then it is of course a lot less obvious what is wrong. >From a usability point of view, this should be fixed in subversion as windows (and most OSX users) expect that the file names should be case insensitive and other uses of subversion work correctly when the wrong case is used, ie: PS C:\temp\WC> svn mkdir APA A APA PS C:\temp\WC> svn mkdir apa\banan A APA\banan At the very least the error message should suggest a fix. /Sebastian -- One laptop per child project: http://laptop.org/
Re: Case sensitivity bug in windows with powershell.
On Mon, Nov 12, 2012 at 2:03 PM, Sebastian Andersson wrote: > On Mon, Nov 12, 2012 at 1:13 PM, Johan Corveleyn wrote: >> Hm, I don't see this problem with "cd" in cmd.exe. > > No, the problem is only with powershell, but I do believe powershell > does what it is designed to do in this case. It uses a unified > location system for more things than just filesystems (you can cd into > the registry, LDAP etc) and some of them are case sensitive so it > preserves the user's typed string. The problem is also with the > Set-Location cmdlet, the old, default "cd" command in powershell. > > Powershell contributes to this problem a bit more; in powershell you > can tab-expand the path names. If you just tab-expand one directory at > a time, it changes to the correct case of it. But if you write two > directories at once (ie apa\Banana), only the second directory gets > changed into the correct case. With a longer path and a single letter > with the incorrect case, then it is of course a lot less obvious what > is wrong. > > > From a usability point of view, this should be fixed in subversion as > windows (and most OSX users) expect that the file names should be case > insensitive and other uses of subversion work correctly when the wrong > case is used, ie: > PS C:\temp\WC> svn mkdir APA > A APA > PS C:\temp\WC> svn mkdir apa\banan > A APA\banan > > At the very least the error message should suggest a fix. OK, I see. I still find the behavior of Powershell pretty strange here. You say that it "preserves the user's typed string", but I do not agree with that: it ignores the casing that's present on disk, and that should be the casing that's preserved and shown everywhere. At least that's my opinion. If it would *really* preserve the user's typed string, then it should say "apa does not exist" (as with a case-sensitive filesystem). If Set-Location(Ex) would be consistent with all other Windows tools, and with the behavior you actually want from subversion, then it would say "OK, I'm case-insensitive here, the user asks for apa, but there is APA on disk, so the user means APA, so I'll act on APA -> c:\temp\WC\APA". But anyway, we probably can't do anything about that Powershell behaviour, and perhaps it's possible to work around that from within subversion. So please go ahead and file an issue for this. -- Johan
Re: Case sensitivity bug in windows with powershell.
On Mon, Nov 12, 2012 at 02:26:05PM +0100, Johan Corveleyn wrote: > But anyway, we probably can't do anything about that Powershell > behaviour, and perhaps it's possible to work around that from within > subversion. So please go ahead and file an issue for this. How would you work around it? Before filing an issue, we should have a vague idea about a workable solution. Or I suppose we could file an issue about finding a workable solution :)
Re: Case sensitivity bug in windows with powershell.
On Mon, Nov 12, 2012 at 2:40 PM, Stefan Sperling wrote: > On Mon, Nov 12, 2012 at 02:26:05PM +0100, Johan Corveleyn wrote: >> But anyway, we probably can't do anything about that Powershell >> behaviour, and perhaps it's possible to work around that from within >> subversion. So please go ahead and file an issue for this. > > How would you work around it? Before filing an issue, we should > have a vague idea about a workable solution. Or I suppose we could > file an issue about finding a workable solution :) Heh :). I admit I don't have a workable solution in mind, but I'm guessing it's possible (but I'm absolutely not the authority in that area, and I don't have the source code at hand here, so my guess might not be worth much :)). Regardless, I have absolutely no problems with issues that are impossible to fix either. They are still legitimate issues and we might as well just track them, even if they will later be closed with a "won't fix" or something like that (with an explanation of why it's not possible). Then at least the information is out there. -- Johan
Re: Subversion Exception
On Nov 12, 2012, at 09:44, bluefoxreg wrote: > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > with as much information as possible about what > you were trying to do. What were you trying to do when this happened? > But please first search the mailing list archives for the error message > to avoid reporting the same problem repeatedly. > You can find the mailing list archives at > http://subversion.apache.org/mailing-lists.html > > Subversion reported the following > (you can copy the content of this dialog > to the clipboard using Ctrl-C): > > In file > > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.10\ext\subversion\subversion\libsvn_wc\diff_local.c' > line 251: assertion failed (del_checksum != NULL) > --- > OK > ---
Re: Case sensitivity bug in windows with powershell.
On Nov 12, 2012, at 07:03, Sebastian Andersson wrote: > Powershell contributes to this problem a bit more; in powershell you > can tab-expand the path names. If you just tab-expand one directory at > a time, it changes to the correct case of it. But if you write two > directories at once (ie apa\Banana), only the second directory gets > changed into the correct case. With a longer path and a single letter > with the incorrect case, then it is of course a lot less obvious what > is wrong. This also describes the behavior of a normal Bash shell on OS X with a normal HFS+ case-insensitive filesystem: tab completion corrects the case of the last typed component only (assuming you've enabled case-insensitive tab completion in the shell, which I have by writing "set completion-ignore-case on" in my ~/.inputrc). However, this particular case difference doesn't seem to cause problems for Subversion on OS X: tmp $ svn --version|head -n 2 svn, version 1.7.7 (r1393599) compiled Nov 9 2012, 20:33:44 tmp $ svnadmin create repo tmp $ svn co file://`pwd`/repo wc Checked out revision 0. tmp $ cd wc wc $ svn mkdir APA A APA wc $ cd apa apa $ svn mkdir banan A banan apa $ .. wc $ svn ci -m x Adding APA Adding APA/banan Committed revision 1. wc $ There are of course several other case difference problems for Subversion on OS X.
Re: Subversion Exception
I was trying to create a patch. It seems to be caused by one of my file being marked as deleted (but was actually deleted in a different check-in). This exception is thrown when svn is trying to generate a patch for that file. I was able to get rid of the exception by reverting the file (since it was already deleted). On Mon, Nov 12, 2012 at 2:07 PM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > > On Nov 12, 2012, at 09:44, bluefoxreg wrote: > > > --- > > Subversion Exception! > > --- > > Subversion encountered a serious problem. > > Please take the time to report this on the Subversion mailing list > > with as much information as possible about what > > you were trying to do. > > What were you trying to do when this happened? > > > But please first search the mailing list archives for the error message > > to avoid reporting the same problem repeatedly. > > You can find the mailing list archives at > > http://subversion.apache.org/mailing-lists.html > > > > Subversion reported the following > > (you can copy the content of this dialog > > to the clipboard using Ctrl-C): > > > > In file > > > > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.10\ext\subversion\subversion\libsvn_wc\diff_local.c' > > line 251: assertion failed (del_checksum != NULL) > > --- > > OK > > --- > > > >
RE: Commit failed Error after upgrading 1.7.7
> >> I recently upgraded Subversion edge to 3.2.0-3352.100 which gave me > >> Subversion 1.7.7. > >> > >> Since then every now and then when I commit I get the following error: > >> > >> Commit > >> Commit failed (details follow): > >> Server sent unexpected return value (500 Internal Server Error) in > >> response to POST request for '/svn/manage/!svn/me' > >> > >> Usually if I just retry the commit it works fine. Not a major issue, > >> but a nuisance. > >> > >> Any ideas? > > > >Look for more details in the apache log file. > > > Paul... I'm not sure which log to look in. Edge has an Error log, Subversion > Log, > Jetty Log, Console log. > > I looked in all of those from today, the error did occur for me this AM and > don't > seem to find a similar error to the one listed above. > > However, the jetty log does have quite a few errors listed. > Does anyone have any more insite into this? I have looked in the logs and don't see anything wrt to the quoted error. It seems to be happening on every commit, and an then an immediate retry will be successful. Thanks, Bob
Re: Commit failed Error after upgrading 1.7.7
On Mon, Nov 12, 2012 at 10:12 PM, Bob Archer wrote: >> >> I recently upgraded Subversion edge to 3.2.0-3352.100 which gave me >> >> Subversion 1.7.7. >> >> >> >> Since then every now and then when I commit I get the following error: >> >> >> >> Commit >> >> Commit failed (details follow): >> >> Server sent unexpected return value (500 Internal Server Error) in >> >> response to POST request for '/svn/manage/!svn/me' >> >> >> >> Usually if I just retry the commit it works fine. Not a major issue, >> >> but a nuisance. >> >> >> >> Any ideas? >> > >> >Look for more details in the apache log file. >> >> >> Paul... I'm not sure which log to look in. Edge has an Error log, Subversion >> Log, >> Jetty Log, Console log. >> >> I looked in all of those from today, the error did occur for me this AM and >> don't >> seem to find a similar error to the one listed above. >> >> However, the jetty log does have quite a few errors listed. >> > > Does anyone have any more insite into this? I have looked in the logs and > don't see anything wrt to the quoted error. > > It seems to be happening on every commit, and an then an immediate retry will > be successful. > Are these clients using serf on these connections? If so, try if switching to neon helps. -- Johan
RE: Commit failed Error after upgrading 1.7.7
> On Mon, Nov 12, 2012 at 10:12 PM, Bob Archer > wrote: > >> >> I recently upgraded Subversion edge to 3.2.0-3352.100 which gave > >> >> me Subversion 1.7.7. > >> >> > >> >> Since then every now and then when I commit I get the following error: > >> >> > >> >> Commit > >> >> Commit failed (details follow): > >> >> Server sent unexpected return value (500 Internal Server Error) in > >> >> response to POST request for '/svn/manage/!svn/me' > >> >> > >> >> Usually if I just retry the commit it works fine. Not a major > >> >> issue, but a nuisance. > >> >> > >> >> Any ideas? > >> > > >> >Look for more details in the apache log file. > >> > >> > >> Paul... I'm not sure which log to look in. Edge has an Error log, > >> Subversion Log, Jetty Log, Console log. > >> > >> I looked in all of those from today, the error did occur for me this > >> AM and don't seem to find a similar error to the one listed above. > >> > >> However, the jetty log does have quite a few errors listed. > >> > > > > Does anyone have any more insite into this? I have looked in the logs and > don't see anything wrt to the quoted error. > > > > It seems to be happening on every commit, and an then an immediate retry > will be successful. > > > > Are these clients using serf on these connections? If so, try if switching to > neon > helps. I have no idea. I am using TortioseSVN 1.7.7, which I am pretty sure defaults to neon. There is no http-library setting in the config file. So, I think it is using neon. Also, I can't seem to figure out in Subversion Edge how to look at the configuration file. BOb
Re: Commit failed Error after upgrading 1.7.7
If you are using LDAP and the server is on Windows there is a bug in Apache 2.2.23 that can cause an HTTP 500 on the first authenticated request for a user. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=54140 Sent from my iPad On Nov 12, 2012, at 5:42 PM, Bob Archer wrote: >> On Mon, Nov 12, 2012 at 10:12 PM, Bob Archer >> wrote: >> I recently upgraded Subversion edge to 3.2.0-3352.100 which gave >> me Subversion 1.7.7. >> >> Since then every now and then when I commit I get the following error: >> >> Commit >> Commit failed (details follow): >> Server sent unexpected return value (500 Internal Server Error) in >> response to POST request for '/svn/manage/!svn/me' >> >> Usually if I just retry the commit it works fine. Not a major >> issue, but a nuisance. >> >> Any ideas? > > Look for more details in the apache log file. Paul... I'm not sure which log to look in. Edge has an Error log, Subversion Log, Jetty Log, Console log. I looked in all of those from today, the error did occur for me this AM and don't seem to find a similar error to the one listed above. However, the jetty log does have quite a few errors listed. >>> >>> Does anyone have any more insite into this? I have looked in the logs and >> don't see anything wrt to the quoted error. >>> >>> It seems to be happening on every commit, and an then an immediate retry >> will be successful. >> >> Are these clients using serf on these connections? If so, try if switching >> to neon >> helps. > > I have no idea. I am using TortioseSVN 1.7.7, which I am pretty sure defaults > to neon. There is no http-library setting in the config file. So, I think it > is using neon. > > Also, I can't seem to figure out in Subversion Edge how to look at the > configuration file. > > BOb >
