Re: assert+fail when copying a directory
Can you reproduce this with a clean checkout? (If so, can you produce the steps for us so we can reproduce the problem) Currently I can only guess that your working copy has somehow invalid data recorded or your target is somehow special in a way your mail doesn't specify, but as you don't provide any information about that there is nothing we can do. The assertion (with the code around it) says that you are not copying a file, nor a directory… But something else shouldn't be possible there. Bert Sent from Windows Mail From: John Crim Sent: Friday, September 5, 2014 3:41 AM To: users@subversion.apache.org Note that this error also occurs in svn, version 1.8.10 (r1615264). On Fri, Aug 29, 2014 at 6:31 AM, John Crim wrote: I first tried copying a directory in TortoiseSvn within the same parent directory, and received the assert error + failure. Then I tried the same operation from the command line and got the same exception: Running Windows 8.1, svn 1.8.8 This operation completely describes what I was doing - after the first error, I ran svn cleanup, svn revert -R . - so I'm starting from a clean state. C:\src\code\Tools\Templates\WebApp\test>svn st C:\src\code\Tools\Templates\WebApp\test>dir Volume in drive C has no label. Volume Serial Number is 6C5D-2637 Directory of C:\src\code\Tools\Templates\WebApp\test 08/29/2014 06:26 AM . 08/29/2014 06:26 AM .. 08/29/2014 06:27 AM DataAccess.IntegrationTests 08/27/2014 10:13 PM Model.UnitTests 08/29/2014 06:27 AM Web.IntegrationTests 0 File(s) 0 bytes 5 Dir(s) 80,145,203,200 bytes free C:\src\code\Tools\Templates\WebApp\test>svn cp Web.IntegrationTests Web.UnitTests A Web.UnitTests svn: E235000: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.6\ext\subversion\subversion\libsvn_wc\wc_db.c' line 4347: assertion faile d (kind == svn_node_file || kind == svn_node_dir) I hope this is helpful, I was pretty surprised to see this use case fail to work. --John
SubVersion crash in TortoiseSVN 1.8.8
This crash happened in TortoiseSVN 1.8.8, which is based on Apache SubVersion 1.8.10, both of which are the latest release versions. It happened on 32-bit Windows XP Professional with Service Pack 3. It occurred when I was trying to view the difference between 2 previous revisions of a file in an SVN repository that uses the svn+ssh:// protocol, on SourceForge. I get this crash very often in TortoiseSVN 1.8.8 and the error message says to post an email to this email address. However the error message is exactly the same every time. So I am only emailing this bug in once even though it keeps happening again and again and again. Please fix it so I don't have to deal with this annoying bug anymore. I think the error message itself, In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\libsvn_wc\wc_db.c' line 8731: assertion failed (svn_dirent_is_absolute(local_abspath)), that error message ought to be more than enough for you to figure out what went wrong, it says exactly what line of source code has the error, line 8731 of wc_db.c, and it says what the error is too. Anyway I get this error ALL THE TIME now so please fix it. Also maybe you should have Apache SubVersion automatically report crash reports to https://drdump.com/ the way TortoiseSVN does so that users like me don't have to manually email these crash reports in and so you can get an accurate count of how often the crashes actually occur. Drdump.com is the new name for crash-server.com, anyway an explanation of it is on the TortoiseSVN site here: http://tortoisesvn.net/crashhandler.html. Automated crash reports would make the program more stable and allow you to accurately track statistics on each type of crash to prioritize fixing the most common ones first, and you wouldn't need people to send in emails of crash reports anymore. Here is the crash log: --- 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. 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.8.8\ext\subversion\subversion\libsvn_wc\wc_db.c' line 8731: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- Thanks, Rich McGrew, open-source programmer
Re: cannot connect to svnserve locally and remotely
James writes: > I got latest subversion setup on my latest Fedora 20. > $svn co svn://devserver/Playground Playground --username bowing > svn: E13: Unable to connect to a repository at URL > 'svn://devserver/Playground' > svn: E13: Can't open file '/home/svn/Playground/format': Permission denied > > The svnserve is running: > > $systemctl status svnserve.service > svnserve.service - Subversion protocol daemon >Loaded: loaded (/usr/lib/systemd/system/svnserve.service; enabled) >Active: active (running) since Fri 2014-09-05 00:10:29 EDT; 2min 16s ago > Process: ExecStart=/usr/bin/svnserve --daemon > --pid-file=/run/svnserve/svnserve.pid $OPTIONS (code=exited, status=0/SUCCESS) > Main PID: 1129 (svnserve) >CGroup: /system.slice/svnserve.service >└─1129 /usr/bin/svnserve --daemon > --pid-file=/run/svnserve/svnserve.pid -r /home/svn One possible cause is that the repository in /home/svn is owned different user from the from user running svnserve and the svnserve user doesn't have OS level access to the files. If this is the case then either use the same user or use group permissions. Another possible cause is that selinux prevents svnserve from accessing any files in /home. Put selinux into the permissive mode and the GUI will alert you to selinux violations and provide hints on how to modify selinux to allow the access. Or move the repository into the location to which selinux allows access. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: cannot connect to svnserve locally and remotely
On Thu, Sep 04, 2014 at 09:20:39PM -0700, James wrote: > I got latest subversion setup on my latest Fedora 20. > > I created repository. > > I modified the svnserve.conf file and the passwd file in that repository. > I modified the firewall to open 3690 to public for TCP. > The svnserve.service is running. but I got E13 error when I try to > connect to it with svn protocol locally (the same machine) and remotely. The > error message is this: > > $svn co svn://devserver/Playground Playground --username bowing > svn: E13: Unable to connect to a repository at URL > 'svn://devserver/Playground' > svn: E13: Can't open file '/home/svn/Playground/format': Permission denied > > The svnserve is running: > > $systemctl status svnserve.service > svnserve.service - Subversion protocol daemon >Loaded: loaded (/usr/lib/systemd/system/svnserve.service; enabled) >Active: active (running) since Fri 2014-09-05 00:10:29 EDT; 2min 16s ago > Process: ExecStart=/usr/bin/svnserve --daemon > --pid-file=/run/svnserve/svnserve.pid $OPTIONS (code=exited, status=0/SUCCESS) > Main PID: 1129 (svnserve) >CGroup: /system.slice/svnserve.service >└─1129 /usr/bin/svnserve --daemon > --pid-file=/run/svnserve/svnserve.pid -r /home/svn > > > how to diagnosis the issue? how to fix it? > > Thanks, > James The user svnserve runs as needs read/write access to the repository. Use chmod(1) to fix acess permissions and chown(1) to fix ownership. Or perhaps use some SELinux tools to adjust access permissions (I don't know which commands to use in that case).
RE: SubVersion crash in TortoiseSVN 1.8.8
Hi, If you want us (or the TortoiseSVN developers, which have their own list) to resolve your problem you should explain us how we can reproduce your problem. The only explanation you give us "It occurred when I was trying to view the difference between 2 previous revisions of a file in an SVN repository that uses the svn+ssh:// protocol, on SourceForge" Doesn't provide me any information to reproduce this. nor does it tell me whether this problem is caused by a bug in TortoiseSVN invoking the Subversion libraries, or in TortoiseSVN itself. We really need more information to even start looking Usually when you would look at two old versions, you don't check the working copy. so that might give the hint that TortoiseSVN accidentally tries to do something in the wrong location. But we can't tell. As you get the error from TortoiseSVN and we as Subversion project don't provide direct support for that projects final releases the request to automatically handle *their* errors doesn't really make sense here. As far as I know TortoiseSVN handles their crashes automatically. So somehow they determined that this isn't a crash that they want/can handle. Bert From: Rich McGrew [mailto:mcgrew_r...@yahoo.com] Sent: vrijdag 5 september 2014 10:47 To: users@subversion.apache.org Subject: SubVersion crash in TortoiseSVN 1.8.8 This crash happened in TortoiseSVN 1.8.8, which is based on Apache SubVersion 1.8.10, both of which are the latest release versions. It happened on 32-bit Windows XP Professional with Service Pack 3. It occurred when I was trying to view the difference between 2 previous revisions of a file in an SVN repository that uses the svn+ssh:// protocol, on SourceForge. I get this crash very often in TortoiseSVN 1.8.8 and the error message says to post an email to this email address. However the error message is exactly the same every time. So I am only emailing this bug in once even though it keeps happening again and again and again. Please fix it so I don't have to deal with this annoying bug anymore. I think the error message itself, In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\lib svn_wc\wc_db.c' line 8731: assertion failed (svn_dirent_is_absolute(local_abspath)), that error message ought to be more than enough for you to figure out what went wrong, it says exactly what line of source code has the error, line 8731 of wc_db.c, and it says what the error is too. Anyway I get this error ALL THE TIME now so please fix it. Also maybe you should have Apache SubVersion automatically report crash reports to https://drdump.com/ the way TortoiseSVN does so that users like me don't have to manually email these crash reports in and so you can get an accurate count of how often the crashes actually occur. Drdump.com is the new name for crash-server.com, anyway an explanation of it is on the TortoiseSVN site here: http://tortoisesvn.net/crashhandler.html. Automated crash reports would make the program more stable and allow you to accurately track statistics on each type of crash to prioritize fixing the most common ones first, and you wouldn't need people to send in emails of crash reports anymore. Here is the crash log: --- 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. 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.8.8\ext\subversion\subversion\lib svn_wc\wc_db.c' line 8731: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- Thanks, Rich McGrew, open-source programmer
Re: SubVersion crash in TortoiseSVN 1.8.8
Well when the error message came up in TortoiseSVN 1.8.8 it said to post it to the Apache SubVersion mailing list and I followed the instructions. Since the window title was "SubVersion Exception!" and the error message said to post it to the Apache SubVersion mailing list I followed the instructions. Yes the error did occur in TortoiseSVN but it didn't give any option to use TortoiseSVN's automatic crash handler, that didn't come up at all, what came up was a window with the text that I copied and pasted. I would assume that the lines: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\libsvn_wc\wc_db.c' line 8731: assertion failed (svn_dirent_is_absolute(local_abspath)) Might mean something to people who know the code and they might be able to look at that line in the code and see what is wrong there but I guess this is a hard to fix thing... I just did a bit of online searching and apparently similar assertions have failed in other lines of code in that same file, wc_db.c, typically when run from TortoiseSVN, and sometimes it gets fixed and sometimes it doesn't. This example: https://groups.google.com/forum/#!topic/tortoisesvn-dev/TwW5UTdVp2Y, it was that same error message in wc_db.c but in line 5710 and it got fixed in r21821 of TortoiseSVN in a fix that Stefan did. So that bug was in TortoiseSVN and not in Apache SubVersion. This other example: http://mail-archives.apache.org/mod_mbox/subversion-users/201204.mbox/%3CCAB84uBU2g02vopgFrRu8a_B8=ealvoykbrvp6hws0z0+saj...@mail.gmail.com%3E, it was that same error message in wc_db.c but in line 6752 and it doesn't seem it got fixed, it seems everyone concluded that it was not a problem in Apache SubVersion but a problem in TortoiseSVN. Well judging by those past examples I guess this is probably a bug in TortoiseSVN, I just posted it to the Apache SubVersion mailing list because that is what the instructions in the error message said to do. I will probably post this as a bug for TortoiseSVN because when I look at those 2 similar previous bugs, in both cases it was a bug in TortoiseSVN and how it called Apache SubVersion, and not a bug in Apache SubVersion. Thank you for the help, I think you are probably correct about this most likely being a bug in TortoiseSVN and not in Apache SubVersion, but we still don't know for sure. If the developers of TortoiseSVN are on this mailing list then maybe I won't have to file a bug because they will read it here, but I guess filing a bug with them would be a good idea anyway. As for how to duplicate the bug: 1) Set up TortoiseSVN 1.8.8 to connect to a SourceForge project that uses SVN using the the svn+ssh:// protocol using your login info to SourceForge. 2) Go to your TortoiseSVN settings from the Start Menu, go to Network, and under SSH, in the SSH Client line, add command line parameters to TortoisePlink.exe for your username and password at SourceForge like so: "C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe" -l username_at_sourceforge -pw password_at_sourceforge 3) Right-click the main folder for the project, choose TortoiseSVN in the context menu, and in that menu choose Show Log. 4) The log messages window will pop up showing the revision history. Select any revision at all on the top part of the screen. 5) The bottom part of the screen will have a list of files modified in whichever revision you pick. Double-click on one of the files down there, or right-click and chose Show Changes, both are equivalent. 6) It will probably prompt you for a password, even though you have TortoiseSVN set up to call the SVN client with a username and password. This doesn't always happen, only happens about half the time. 7) If you try typing in a password and hitting OK it will just prompt you for a password again and again forever in an infinite loop and each time will be considered an authentication failure by SourceForge (which you'll get an error message about later on), so don't do that. Instead, hit OK without typing in a password. 8) The error message I originally posted about a bug in Apache SubVersion that you should post to the SubVersion mailing list might occur if you were prompted for a password and didn't type one in, and it will always be that exact same error message. There is also a chance you might actually get to see the changes in the file between the 2 revisions and have it work correctly. Additionally, there is a chance you could get prompted for a password again and have to hit OK again. Lastly there is a chance you could get an error message from SourceForge saying that there are too many authentication failures for your username there. So that's 4 different possibilities here and just one of them is the error message that says to copy and paste it to the SubVersion mailing list. It seems kind of random at this point. Well those are the steps to reproduce the bug, and as step 8 shows it is intermittent an
Assert with Github and tortoisesvn
When I try to sync my local folder with the github repository is returning this assert: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\libsvn_wc\update_editor.c' line 1550: assertion failed (action == svn_wc_conflict_action_delete) Breno Magalhaes
Re: cannot connect to svnserve locally and remotely
Thank you guys. Connected It is selinux stop the connection to the svnserve. I should mentioned that I have create an user group and changed the owner and permission on the repository. I also modified the svnserve.conf and passwd files of that repository and enabled to use passwd and added users in the passwd file. But it seems the password policy doesn't work. Anyuser can connect to that repository. I read the svn-book and few online instructions. I do enabled the policy but it doesn't work for me. Any thoughts? Maybe because my repository is empty (no custom files yet)? But I guess it shouldn't matter, right? Another question is how can I set the selinux allows the svnserve connections? I don't want to turn it off just because the subversion. Thanks, James On Friday, September 5, 2014 5:31 AM, Philip Martin wrote: James writes: > I got latest subversion setup on my latest Fedora 20. > $svn co svn://devserver/Playground Playground --username bowing > svn: E13: Unable to connect to a repository at URL > 'svn://devserver/Playground' > svn: E13: Can't open file '/home/svn/Playground/format': Permission denied > > The svnserve is running: > > $systemctl status svnserve.service > svnserve.service - Subversion protocol daemon >Loaded: loaded (/usr/lib/systemd/system/svnserve.service; enabled) >Active: active (running) since Fri 2014-09-05 00:10:29 EDT; 2min 16s ago > Process: ExecStart=/usr/bin/svnserve --daemon > --pid-file=/run/svnserve/svnserve.pid $OPTIONS (code=exited, status=0/SUCCESS) > Main PID: 1129 (svnserve) >CGroup: /system.slice/svnserve.service >└─1129 /usr/bin/svnserve --daemon > --pid-file=/run/svnserve/svnserve.pid -r /home/svn One possible cause is that the repository in /home/svn is owned different user from the from user running svnserve and the svnserve user doesn't have OS level access to the files. If this is the case then either use the same user or use group permissions. Another possible cause is that selinux prevents svnserve from accessing any files in /home. Put selinux into the permissive mode and the GUI will alert you to selinux violations and provide hints on how to modify selinux to allow the access. Or move the repository into the location to which selinux allows access. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
SVN skipping revert after add for file path with spaces in it
Hi, I'm having trouble un-adding a directory (recursively) that has spaces in its name. I am doing this on Windows 8.1 through a batch script. An example of my code is below: set PATHWSPACES=%CD% svn add "PATHWSPACES"\subdir1\ svn revert "PATHWSPACES"\subdir1\subdir2\ --recursive When I run the batch script, the files are added correctly, but I get this line when the directory is supposed to be reverted: Skipped 'C:\Path with spaces\subdir1\subdir2' Setting the PATHWSPACES variable using quotes of any kind does not work. However, what does work is typing out the complete path which is not feasible for what I'm trying to do with the batch script. So, this works: Set PATHWSPACES=%CD% svn add "PATHWSPACES"\subdir1\ svn revert "C:\Path with spaces\subdir1\subdir2\" --recursive Putting quotes around the entire path or putting quotes around the variable and the entire path also does not work. I get the following messages: For code that is: svn revert "PATHWSPACES\subdir1\subdir2" --recursive svn: E155007: 'C:Path' is not a working copy For code that is: svn revert ""PATHWSPACES"\subdir1\subdir2\" --recursive Skipped 'C:\Path with spaces\subdir1\subdir2" -recursive' Help! What is going on? Unfortunately, I can't change to a path name without spaces. Thanks, Simone
Re: SVN skipping revert after add for file path with spaces in it
On 2014-09-05 22:37, Simone Agha wrote: > Hi, > > I'm having trouble un-adding a directory (recursively) that has spaces in its > name. I am doing this on Windows 8.1 through a batch script. An example of > my code is below: > > set PATHWSPACES=%CD% > svn add "PATHWSPACES"\subdir1\ > svn revert "PATHWSPACES"\subdir1\subdir2\ --recursive > > When I run the batch script, the files are added correctly, but I get this > line when the directory is supposed to be reverted: > > Skipped 'C:\Path with spaces\subdir1\subdir2' > > Setting the PATHWSPACES variable using quotes of any kind does not work. > However, what does work is typing out the complete path which is not feasible > for what I'm trying to do with the batch script. So, this works: > > Set PATHWSPACES=%CD% > svn add "PATHWSPACES"\subdir1\ > svn revert "C:\Path with spaces\subdir1\subdir2\" --recursive > > Putting quotes around the entire path or putting quotes around the variable > and the entire path also does not work. I get the following messages: > For code that is: svn revert "PATHWSPACES\subdir1\subdir2" > --recursive >svn: E155007: 'C:Path' is not a working copy > For code that is: svn revert ""PATHWSPACES"\subdir1\subdir2\" > --recursive > Skipped 'C:\Path with spaces\subdir1\subdir2" -recursive' > > Help! What is going on? Unfortunately, I can't change to a path name without > spaces. > I can think about two solutions 1) instead using "PATHWSPACES"\subdir1\ use "PATHWSPACES\subdir1\" 2) cd "PATHWSPACES\subdir1\" && svn revert -R Even windows self has today issues with masking spaces in the path, you will find x samples with quoted paths in the registry or on technet. Not exactly your issue but describes how to use cmd and quotes http://technet.microsoft.com/en-us/library/cc771320.aspx
Re: SVN skipping revert after add for file path with spaces in it
I would start by removing the final ‘\' from the paths you create yourself, as they are never necessary and affect the quoting rules (in some cases ignoring the final “). In general you should never double the quoting characters. Then you get to the boundary between parsing in 'svn’ and 'cmd', which both have their own rules. You should work from there as obviously your examples are not complete, or you would use a literal ‘PATHWSPACES' as your subpart. (You miss the % surrounding). If possible I would recommend using the quotes only at the outside of arguments. And make sure you avoid ‘@' characters, or escape them by adding a final ‘@' add the end of the path. Bert Sent from Windows Mail From: olli hauer Sent: Friday, September 5, 2014 11:44 PM To: users@subversion.apache.org Cc: Simone Agha On 2014-09-05 22:37, Simone Agha wrote: > Hi, > > I'm having trouble un-adding a directory (recursively) that has spaces in its > name. I am doing this on Windows 8.1 through a batch script. An example of > my code is below: > > set PATHWSPACES=%CD% > svn add "PATHWSPACES"\subdir1\ > svn revert "PATHWSPACES"\subdir1\subdir2\ --recursive > > When I run the batch script, the files are added correctly, but I get this > line when the directory is supposed to be reverted: > > Skipped 'C:\Path with spaces\subdir1\subdir2' > > Setting the PATHWSPACES variable using quotes of any kind does not work. > However, what does work is typing out the complete path which is not feasible > for what I'm trying to do with the batch script. So, this works: > > Set PATHWSPACES=%CD% > svn add "PATHWSPACES"\subdir1\ > svn revert "C:\Path with spaces\subdir1\subdir2\" --recursive > > Putting quotes around the entire path or putting quotes around the variable > and the entire path also does not work. I get the following messages: > For code that is: svn revert "PATHWSPACES\subdir1\subdir2" > --recursive >svn: E155007: 'C:Path' is not a working copy > For code that is: svn revert ""PATHWSPACES"\subdir1\subdir2\" > --recursive > Skipped 'C:\Path with spaces\subdir1\subdir2" -recursive' > > Help! What is going on? Unfortunately, I can't change to a path name without > spaces. > I can think about two solutions 1) instead using "PATHWSPACES"\subdir1\ use "PATHWSPACES\subdir1\" 2) cd "PATHWSPACES\subdir1\" && svn revert -R Even windows self has today issues with masking spaces in the path, you will find x samples with quoted paths in the registry or on technet. Not exactly your issue but describes how to use cmd and quotes http://technet.microsoft.com/en-us/library/cc771320.aspx
