[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Svn 1.4 on slackware

From: Ryan Schmidt <subversion-2007a_at_ryandesign.com>
Date: 2007-03-26 04:41:02 CEST

Please keep the discussion on the mailing list by using the Reply To
All feature of your email program when you reply. I may not
personally know the answers to your questions, so it's best to keep
it on the list so that others who know the answer can respond.

On Mar 25, 2007, at 18:56, Colleen Dick wrote:

>> There is no "reattach command", nor any reason for one. Depending on
>> what server you're using to serve the repository (apache or
>> svnserve), simply configure that server to tell it where the
>> repository is. If you're using apache, set the proper repository path
>> in your httpd.conf, in the SVNPath or SVNParentPath line. You said
>> you're using svnserve, so you need to figure out where on Slackware
>> the configuration file is that starts svnserve, and fix it to use the
>> repository root parameter to tell it where your repository is.
>
> I have a line in inetd to do svnserve but I've been looking all
> over the
> box for some config for svnserve that has that and I haven't found
> one.

It's not in a config file; it's a command line parameter that you
pass to the svnserve program when you start it. Please see the book...

http://svnbook.red-bean.com/en/1.2/svn.serverconfig.svnserve.html

...especially where it shows how to use the -r option to svnserve.
Since you're running it from inetd, you'll probably also want to make
sure svnserve is being started with the --inetd option.

> Also I'm still experience a fundamentally more basic problem when I
> run
> the svn commit like I use to from external host it times out when
> trying
> to talk to the server, but it does respond on the local box

On Mar 25, 2007, at 19:01, Colleen Dick wrote:

> Actually I ended up doing a dump, recreate and reload on one
> repository
> which seem to be OK but I lied. Connection is refused on localhost as
> well.

Ok, you can dump and load if you like. Some performance improvements
were made in 1.4 which you only get if you dump and load, so you may
enjoy those. But it didn't help with the fundamental inability to
connect, right? You still can't connect to your svnserve, either from
the local machine or from another?

On Mar 25, 2007, at 19:43, Colleen Dick wrote:

> Fails to connect
>
> My svnserve is set up to run on inetd. We only commit every day a
> couple of times, there is no reason for it to be a constant-on daemon
>
> In inetd.conf there is a command to run it, it says nothing of
> where the
> repo is, and it always worked before.

Have you in the past been specifying the absolute path to the
repository in your access URLs? As far as I know, that would be
necessary if you do not tell svnserve where to serve from. Something
like:

svn ls svn://svn.example.com/absolute/path/on/server/to/repository/

> If I telnet <svnhost> 3690 would that ever connect if it's inetd even
> if things work??

I have no experience with inetd so I don't know. But I have seen
telneting to 3690 suggested in the past for debugging svnserve
connectivity issues.

> There is a svnserve.conf down inside each repo but no mention of the
> repo loc (you're already there hahah)...
>
> In each users .svn dir it tells where the repo is for that directory
> that hasnt changed on external hosts
>
> I had to create the 3690 port in services. I restarted inetd. Is
> there anything else I need to restart. All networking is kinda tough
> cuz the svn server is remote if I ifdown eth0 it will kick me off
> and I
> can't get back on. What reads that services file?

I don't know; I'll let someone else answer.

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 26 04:41:26 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.