Community
Participate
Working Groups
At some time I could use SVN on build.eclipse.org with urls like: svn://localhost/svnroot/tools/org.eclipse.objectteams/ when I started to build on build2, I had to change this to svn://build/svnroot/tools/org.eclipse.objectteams/ but after the recent server upgrade none of these work, I have to go back to svn://dev/svnroot/tools/org.eclipse.objectteams/ I'm not sure about the performance difference, but this is unfortunate for SVN working copies on build, where I cannot commit the changes I made locally (connection refused). I'm not sure if I can simply re-parent the working copies. Is it possible to make SVN locally accessible again? I think the directories are mounted alright, but some SVN server seems to be missing on build, could that be?
I've restarted xinetd and things seem to be happy. hudsonbuild@build:~> svn list svn://localhost/svnroot/tools/org.eclipse.objectteams/ branches/ tags/ trunk/ -M.
Thanks indeed, I can access SVN on build again, however, somehow this seems to be a read-only connection? $ svn commit svn: Commit failed (details follow): svn: Authorization failed I can still commit remotely, but changes done locally on build I cannot commit. Is that by intention? (I tried all sorts of things to tell svn about my username) Sorry, to bother again..
Well the only way to commit is via svn+ssh or HTTPs(if your repo is setup for it). I would be really surprised if you were able to commit in the past using just svn as that is for anonymous read only access. Certainly I can commit to my sandbox with with the svn+ssh://localhost syntax. -M.
(In reply to comment #3) > Well the only way to commit is via svn+ssh or HTTPs(if your repo is setup for > it). I would be really surprised if you were able to commit in the past using > just svn as that is for anonymous read only access. > > Certainly I can commit to my sandbox with with the svn+ssh://localhost syntax. > > -M. Thanks for clarification. In fact I can't remember exactly how I committed changes made on build. Re-closing, as the original issue is indeed resolved.
