 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Country Specific / UK Mac Group / May 2008svn problems
svn used to work on my server, but it no longer seems to. It says authentication error when trying to connect to it with anything. I have checked the authentication file, which seems ok. It works as a LaunchDemon on my server (OSX 10.4.latest server). Or should I say doesn't. Everything else works, I can get files, find out which are modified. I can even add. I just cant update modified files. Any ideas?  SignatureWoody www.alienrat.com > svn used to work on my server, but it no longer seems to. It says > authentication error when trying to connect to it with anything. [quoted text clipped - 7 lines] > can even add. I just cant update modified files. > Any ideas? Way back when I was using svn (about 2+ years ago), I found I often had to 'unwedge' the svn database that ran the repository on the server. I can't remember the exact incantation, but it's well documented in the docs. Could this be a solution? > Way back when I was using svn (about 2+ years ago), I found I often had > to 'unwedge' the svn database that ran the repository on the server. I > can't remember the exact incantation, but it's well documented in the > docs. Could this be a solution? It could also be nature's way of telling you to use a less broken VCS. Git and mercurial are popular, git probably more so. Cheersm Chris > > Way back when I was using svn (about 2+ years ago), I found I often had > > to 'unwedge' the svn database that ran the repository on the server. I [quoted text clipped - 3 lines] > It could also be nature's way of telling you to use a less broken VCS. > Git and mercurial are popular, git probably more so. I don't care what the system is, as long as I can use something like TortoiseSVN or clone on the mac and PC to operate it. Can I do that? SignatureWoody www.alienrat.com >>> Way back when I was using svn (about 2+ years ago), I found I often had >>> to 'unwedge' the svn database that ran the repository on the server. I [quoted text clipped - 8 lines] > > Can I do that? There's a tortoise for one of them on Windows. Not so much on the Mac though :-( Cheers, Chris > >>> Way back when I was using svn (about 2+ years ago), I found I often had > >>> to 'unwedge' the svn database that ran the repository on the server. I [quoted text clipped - 11 lines] > There's a tortoise for one of them on Windows. Not so much on the Mac > though :-( That is not so useful then. I like that way of working, but I am not that religeous about VCS systems, as long as I can get it working. SignatureWoody www.alienrat.com >>>>> Way back when I was using svn (about 2+ years ago), I found I often had >>>>> to 'unwedge' the svn database that ran the repository on the server. I [quoted text clipped - 14 lines] > That is not so useful then. I like that way of working, but I am not > that religeous about VCS systems, as long as I can get it working. Git comes with a couple of Tk-based GUIs - gitk and git-gui. The Macports port includes them both, so you can judge how ugly as sin they are :-) Cheers, Chris > >>>>> Way back when I was using svn (about 2+ years ago), I found I often had > >>>>> to 'unwedge' the svn database that ran the repository on the server. I [quoted text clipped - 18 lines] > Macports port includes them both, so you can judge how ugly as sin they > are :-) Yes, you lost me at Macports! SignatureWoody www.alienrat.com > Git comes with a couple of Tk-based GUIs - gitk and git-gui. The > Macports port includes them both, so you can judge how ugly as sin they > are :-) I rarely use standalone GUIs - either they are integrated into my IDE or I use the cmd-line. And anyway, having converted from cvs to svn, I'm not about to switch again unless there is a major advantage in doing so; ie the pain has to be worth the gain. Nor do I want o be using different VCSs for different projects (for a time I had both cvs and svn projects on the go, and I'm not going through that again). What's so special about git? >> Git comes with a couple of Tk-based GUIs - gitk and git-gui. The >> Macports port includes them both, so you can judge how ugly as sin they [quoted text clipped - 8 lines] > > What's so special about git? It has a GUI which you don't need to use? Cheers, Chris In article <a12c83da-d5ea-4fc3-ad4c-332167210e12@w7g2000hsa.googlegroups.com>, > What's so special about git? For me, the important features are disconnected operation and (oddly enough) svn support. We have a group svn server. I use git to sync to it on my laptop, then I can head off to somewhere with no internet access -- park, cafe, whatever -- and commit/revert/branch/merge/etc to my heart's content. Then, when I'm back at my desk, a simple "git svn dcommit" will merge all my changes back to the svn server. Of course, this isn't unique to git; I'm pretty sure you can do much the same with Mercurial, Bazaar, etc. Oh, and "git bisect" -- find the commit that introduced a bug by a binary search -- is pretty handy. Cheers, John > In article > <a12c83da-d5ea-4fc3-ad4c-332167210...@w7g2000hsa.googlegroups.com>, [quoted text clipped - 9 lines] > Then, when I'm back at my desk, a simple "git svn dcommit" will merge > all my changes back to the svn server. Neat, but how often would I want to be doing repository maintenance offline? It might be useful for moving the repository from one server to another (of different architectures or versions of BDB), I guess. Probably worth a look though. >> In article >> <a12c83da-d5ea-4fc3-ad4c-332167210...@w7g2000hsa.googlegroups.com>, [quoted text clipped - 13 lines] > offline? It might be useful for moving the repository from one server > to another (of different architectures or versions of BDB), I guess. John wasn't saying you'd be doing repository *maintenance* offline. You'd be committing stuff while offline, doing everything you'd normally do while online. The main (and confusing) thing about git and mercurial et al is that there are lots of repositories, and the tools don't enforce any policy about which one is "it". (Whatever "it" means.) But this lets you work on an offline repository and then sync things up afterwards with other repositories, and it allows other modes of working as well. > Probably worth a look though. Quite a number of open source projects are moving from svn to mercurial and git. Cheers, Chris > John wasn't saying you'd be doing repository *maintenance* offline. OK, had a quick browse through the docs and it works on a different premise than the one I'm used to. There's no central repository (though it allows one if you want to work that way); everyone has a complete copy of the repository, history, branches and all, and it works by sync'ing repositories rather than between a working copy and a central repository. I can see that it would be useful if you regularly run off to a private island in the Pacific to do your software development. And you never have to worry about losing the central repository, since someone will have a copy... > You'd be committing stuff while offline, doing everything you'd > normally do while online. Since I can connect to my svn server over https, I'm rarely "offline": it's even useable over GPRS for checking in a few files or looking at an older rev. of a file. Don't how useful it'd be for me, but I'll give it a shot one day in my copious spare time. > Way back when I was using svn (about 2+ years ago), I found I often had > to 'unwedge' the svn database that ran the repository on the server. I > can't remember the exact incantation, but it's well documented in the > docs. Could this be a solution? You're kidding me. My svn repositories on Linux don't require this and they've been running for a coupel of years. Anyway, if he can get stuff out of the repository but not update, it could be a permission or lock problem. >> Way back when I was using svn (about 2+ years ago), I found I often had >> to 'unwedge' the svn database that ran the repository on the server. I [quoted text clipped - 3 lines] > You're kidding me. My svn repositories on Linux don't require this and > they've been running for a coupel of years. Tis true, on Suse 9ish. It was down to the db backend used. The default used to be the BerkleyDB, but now is something else (SQLite?). http://studenthelp.itee.uq.edu.au/faq/subversion/Version_Control_with_Subversion .htm#svn-ch-5-sect-3.4 > Anyway, if he can get stuff out of the repository but not update, it > could be a permission or lock problem. Could be... > > Way back when I was using svn (about 2+ years ago), I found I often had > > to 'unwedge' the svn database that ran the repository on the server. I [quoted text clipped - 6 lines] > Anyway, if he can get stuff out of the repository but not update, it > could be a permission or lock problem. It is undoubtadly some kind of permissions problem, but I know not what. SignatureWoody www.alienrat.com >> Anyway, if he can get stuff out of the repository but not update, it > > could be a permission or lock problem. > > It is undoubtadly some kind of permissions problem, but I know not what. What connection method are you using? svnserve, ssh, DAV? With the first, the server process has to own the repository and everything underneath it. With the 2nd, the ssh user you use to connect (generally yourself) must have write perm to the repository dir and everything below it. With the last, the httpd process (apache/nobody/ www/etc) must have write perm. What I generally do when setting up svn on a new system is to create a user & group svn/svn that owns the svn binaries and repositories. Then I add any users who need to access svn directly (either locally or via ssh) to the svn group, and also the httpd user (apache &c). Then I set the group sticky bit on the svn repository (chmod g+s). Finally, I modify the apachectl and svnserve initscript to set the umask so that files are created group-writeable. This allows users to access the svn repository using any combination of methods and not trip up one another. If it is indeed a wedged DB, the SVN book goes into great detail on how to the recover from it (chp 5). >>> Anyway, if he can get stuff out of the repository but not update, it >> > could be a permission or lock problem. [quoted text clipped - 7 lines] > everything below it. With the last, the httpd process (apache/nobody/ > www/etc) must have write perm. It is a svnserve connection. There is a user subversion and in its user folder there is the repository. Just to be on the safe side I did a chown -R subversion:staff repository, but nothing changed. I checked repository/conf/svnserve.conf and password-db points to passwd which contains all the username/passwords Just to be on the safe side I put the username/passwords in svnserve as well. > What I generally do when setting up svn on a new system is to create a > user & group svn/svn that owns the svn binaries and repositories. Then [quoted text clipped - 5 lines] > repository using any combination of methods and not trip up one > another. I don't have the group (I used to on the old linux server.) I will change that and see if ti helps > If it is indeed a wedged DB, the SVN book goes into great detail on > how to the recover from it (chp 5). I will have a look at that, thanks SignatureWoody >>>> Anyway, if he can get stuff out of the repository but not update, it >>> > could be a permission or lock problem. [quoted text clipped - 17 lines] > Just to be on the safe side I put the username/passwords in svnserve as > well. ok, found the problem, it was between the chair and the keyboard. I must have imported the repository wrong in the first place. I had a thought that I couldn't remember if that repository had ever worked on this server. I haven't touched that project for a while, and last time I did, when I had finished I put it under subversion. The other projects there had been there for years, and this was the only one that was added since I used OSX server, when I moved house a few years ago. I had also not commited on this machine or the iMac, as they are new. I edited a file in the ratwarehouse project, and selected commit, and it came up with a dialog box asking for username/password. Entered those and it commited fine. So I typed svn list svn://mini.alienrat.ar and got a list of about 10 projects, which is all the projects there, other than the project in question, so I tried svn list svn://mini.alienrat.ar/nfrs and it listed 'trunk' So I had a look on the disk and got: mini:~/repository subversion$ ls -la total 16 drwxr-xr-x 10 subversi staff 340 Jan 1 18:59 . drwxr-xr-x 15 subversi staff 510 Oct 1 2006 .. -rw-r--r-- 1 subversi staff 229 Sep 30 2006 README.txt drwxr-xr-x 5 subversi staff 170 May 13 22:29 conf drwxr-xr-x 2 subversi staff 68 Sep 30 2006 dav drwxr-sr-x 10 subversi staff 340 May 16 10:48 db -r--r--r-- 1 subversi staff 2 Sep 30 2006 format drwxr-xr-x 11 subversi staff 374 Sep 30 2006 hooks drwxr-xr-x 4 subversi staff 136 Sep 30 2006 locks drwxr-xr-x 9 subversi staff 306 Jan 1 18:59 nfrs with that project stuck at the end. I looked in that directory, and sure enough there was a complete replication, including a conf folder, with a configuration file that wasn't set. Set that, and all is fine! Don't know how I did that, but svn is hardly very friendly at the best of times and at least it is fine now. SignatureWoody > I must have imported the repository wrong in the first place. I think you created a new respository within that directory. You can probably move it up a level, but at the expense of losing the history, >> I must have imported the repository wrong in the first place. > > I think you created a new respository within that directory. You can > probably move it up a level, but at the expense of losing the history, Well, there isn't much history as it has only had one change since being imported (and it was a huge change that affected everything) but as it is working I am tempted to leave it that way! SignatureWoody > Well, there isn't much history as it has only had one change since being > imported (and it was a huge change that affected everything) but as it is > working I am tempted to leave it that way! In that case, easiest thing to do is to export the head rev, then re-import it. svn export svn://mini.alienrat.ar/nfrs/trunk/...etc... /some/where mv :~/repository subversion/nfrs /somewhere/else svn mkdir svn://mini.alienrat.ar/nfrs/trunk cd /some/where svn import svn://mini.alienrat.ar/nfrs/trunk or something like it. SignatureSak Wathanasin Network Analysis Limited http://www.network-analysis.ltd.uk > > Well, there isn't much history as it has only had one change since being > > imported (and it was a huge change that affected everything) but as it is [quoted text clipped - 10 lines] > > or something like it. That seemed to work. Ta. SignatureWoody www.alienrat.com |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.