Version: SVN (using KDE KDE 3.4.1) Installed from: Debian testing/unstable Packages OS: Linux Hi, I'm using SVN version of kdevelop and to me it seems that the subversion support is "broken". I have a project, which I do manage via svn, but since now I used the command line svn client to do so. Now I wanted to switch to kdevelop's svn support, so I chose to load the VCS Plugin and chose Subversion as VCS. Looking at the Version Control widget, I can't find any line edit to tell kdevelop an url, so I guess it's taking it from the .svn dirs. However this does _not_ work, I can't do anything from the Subversion menu, always get an error message telling me that the kio_job exited. I noticed that the URL that was use was svn+http://blah, which seemed like a default, so I grepped the sources and finally found, which attribute in <project>.kdevses is responsible for setting the base url. But changing that attribute in my project file doesn't do anything at all, still the actions from the subversion context menu use svn+http://blah. Then I put a kdDebug() statement in restorePartialProject() to check wether the settings get loaded at all and they don't. I'm not sure how the startup stuff is working, i.e. in which order all the functions are run, but VCSManager gets loaded and the <project>.kdevelop project file has an element for the subversion VCS plugin. The subversion plugin gets loaded too, but it seems that it is not in the plugins list in ProjectSession::restoreFromFile, thus the restorePartialProject() function is never invoked on it. Also creating a new project with subversion support does not work, nothing is checked in, but the 3 dirs (vendor,tags,branches) are created, but I guess that's another bug report... Andreas
I think I have the same bug. I can commit changes to my repository via "svn commit" but I can't do it via kdevelop. It fails after Entering a Log Message(I suppose this untitled Dialog is for entering a Commit Message) with the Mesage described above This is on GenToo with KDE 3.4.2 and KDevelop 3.2.2
Hi, I finally found a way to debug the kio_svn slave and it seems that something in kio_svn::update() is beeing done wrong, causing a segfault deep within libsvn. This is on a recent debian sid, with kdelibs4c2 compiled with debug=full so the slave won't timeout and kdevelop svn from 3.4 branch. I also noted a lot of slave not connected to application messages in the kdeinit-output-window but I think this was only while the slave was "suspended".. Now here is the backtrace from the SIGSEGV: #0 0xb7e32867 in main_arena () from /lib/tls/libc.so.6 #1 0xb67bc106 in svn_wc__maybe_set_read_only () from /usr/lib/libsvn_wc-1.so.0 #2 0xb6727c8b in svn_ra_dav__rev_prop () from /usr/lib/libsvn_ra_dav-1.so.0 #3 0xb6717854 in ne_xml_doc_encoding () from /usr/lib/libneon.so.24 #4 0xb64ed8a1 in xmlSkipBlankChars () from /usr/lib/libxml2.so.2 #5 0xb64f6068 in xmlParseChunk () from /usr/lib/libxml2.so.2 #6 0xb6717d9c in ne_xml_parse () from /usr/lib/libneon.so.24 #7 0xb6717e24 in ne_xml_parse_v () from /usr/lib/libneon.so.24 #8 0xb6716b95 in ne_redirect_location () from /usr/lib/libneon.so.24 #9 0xb670dbb9 in ne_read_response_block () from /usr/lib/libneon.so.24 #10 0xb670eacd in ne_request_dispatch () from /usr/lib/libneon.so.24 #11 0xb6730429 in svn_ra_dav__set_neon_body_provider () from /usr/lib/libsvn_ra_dav-1.so.0 #12 0xb67309ff in svn_ra_dav__parsed_request () from /usr/lib/libsvn_ra_dav-1.so.0 #13 0xb67283b0 in svn_ra_dav__rev_prop () from /usr/lib/libsvn_ra_dav-1.so.0 #14 0xb67a4001 in svn_wc_crawl_revisions2 () from /usr/lib/libsvn_wc-1.so.0 #15 0xb67df308 in svn_client__update_internal () from /usr/lib/libsvn_client-1.so.0 #16 0xb67df602 in svn_client_update () from /usr/lib/libsvn_client-1.so.0 #17 0xb7f9e5eb in kio_svnProtocol::update () from /usr/lib/kde3/kio_svn.so #18 0xb7fa14aa in kio_svnProtocol::special () from /usr/lib/kde3/kio_svn.so #19 0xb7b73745 in KIO::SlaveBase::dispatch (this=0xbfebd8d0, command=77, data=@0xbfebd878) at /home/andreas/compiling/kde_deb/kdelibs-3.4.3/./kio/kio/slavebase.cpp:1089 #20 0xb7b721b8 in KIO::SlaveBase::dispatchLoop (this=0xbfebd8d0) at /home/andreas/compiling/kde_deb/kdelibs-3.4.3/./kio/kio/slavebase.cpp:290 #21 0xb7f9d2c1 in kdemain () from /usr/lib/kde3/kio_svn.so #22 0x0804f0fd in launch (argc=4, _name=0x819f704 "kio_svn", args=0x819f778 "", cwd=0x0, envc=0, envs=0x819f77c "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x8051ccb "0") at /home/andreas/compiling/kde_deb/kdelibs-3.4.3/./kinit/kinit.cpp:626 #23 0x0804f75a in handle_launcher_request (sock=8) at /home/andreas/compiling/kde_deb/kdelibs-3.4.3/./kinit/kinit.cpp:1192 #24 0x0804fdce in handle_requests (waitForPid=0) at /home/andreas/compiling/kde_deb/kdelibs-3.4.3/./kinit/kinit.cpp:1393 #25 0x08050473 in main (argc=1, argv=0xbfebdf64, envp=0xbfebdf6c) at /home/andreas/compiling/kde_deb/kdelibs-3.4.3/./kinit/kinit.cpp:1849 I hope this helps in debugging, later today I'll have kdesdk with debug=full too, so that I can provide a backtrace with exact line numbers (I don't know why it's not taking the debug symbols from the kdesdk-dbg package). Andreas
this shows up in my brand new kdevelop 3.3 i'm trying to update a present svn working copy which uses svn:// kdevelop thinks it is using svn+http:// , and gives an error message accomplishes nothing
please give a try to latest KDE 3.5 branch kdesdk/kioslave/kio_svn Nicolas Escuder committed a bugfix that should fix at least some crashes. Mik
Hi, got around to rebuild debian's kdesdk with the diff from 3.5 branch. From here it looks like all that was done was that the svn ctx now is not a pointer anymore. Now there is a change, only it doesn't make it better: The error message now opens up instantly whereas IIRC earlier it took a few seconds. Andreas
PS: Using kdesvn's kioslave as drop-in replacement for kdesdk's kioslave works perfectly well with kdevelop.
Due to a message on kdevelop-devel I tried this today and now it works. I checked both update and commit and am now using kdesdk from KDE 3.5.2. Also note that I'm using kdevelop-3.4 svn checkout from today. Andreas
There were changes in SVN part and it seems to work now for me. Closing as fixed.