[SVN] Unrecognized URL scheme

[GWTommy]

Enkele weken geleden heb ik op mijn webserver die DirectAdmin draait een SVN server laten draaien via Apache. Ik heb deze DirectAdmin plugin gebruikt:
http://code.google.com/p/dasvn/wiki/Installation
Werkt allemaal goed. Wel nu wil ik via een shell script via SVN wat updaten op de server zelf. Het gaat om code voor een web applicatie die ik naar de SVN server commit die bij uitvoering van het shell script van de SVN server gehaald moet worden.

Hiervoor dacht ik simpelweg het volgende te gebruiken:

svn checkout http://user:pass@server/svn/repository/

Helaas blijkt dit niet te werken aangezien ik deze fout krijg:

svn: Unrecognized URL scheme for 'http://user:pass@server/svn/repository/'

Nu blijkt dat mijn SVN zo gecompiled is zonder ondersteuning voor http via mod_dav, exact hoe ik dus mijn SVN server draai. Hoe ik dit anders aanpak is mij een raadsel. Ik heb gelezen dat dit komt omdat 'neon' niet is geïnstalleerd, dit heb ik geïnstalleerd en SVN hiermee gecompiled. Mocht niet baten. Nou moet ik eerlijk zeggen dat ik weet hoe ik iets moet compilen, maar het liefst doe ik dit wel met een makkelijke handleiding er bij.

Weet iemand of ik iets heb gemist of dat ik simpelweg een gruwelijk domme fout maak? Hoe kan ik dit oplossen? Thnx

Output van svn --version:

[admin@web]# svn --version
svn, version 1.6.5 (r38866)
   compiled Dec  9 2012, 21:50:33

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

Is er nog meer informatie die jullie nodig hebben?
Overigens blijkt hier al duidelijk uit dat het met neon compilen niet echt heeft gewerkt

[Hero of Time]

Je moet modsvn in Apache laden, en daar de juiste vhost definitie mee maken. Dan krijg je van Apache een login prompt. Je gebruikt dan niet http://user:pass@server/locatie, wat in feite onveilig is, je kan het wachtwoord zo uit je bash-history halen. Standaard wordt overigens je inlognaam gebruikt bij een svn co. Dan hoef je alleen maar je wachtwoord op te geven. Als je een afwijkende username hebt, dan geef je deze op met een argument bij het svn commando (--username).

[CyBeR]

Hero, leuk maar zijn probleem is dat zijn svn client geen http ondersteunt.

GWTommy: als je niet zelf een SVN client kunt compilen en op die server kunt zetten cq die op een andere manier kunt installeren rest je maar één ding, en dat is je repository ook via het svn protocol beschikbaar maken.

[ Voor 8% gewijzigd door CyBeR op 10-12-2012 14:53 ]

[FiscBiker]

De uitvoer van de volgende commando's kan behulpzaam zijn:

code:

ldd `which svn`

en

code:

uname -a

[borft]

sowieso, als je zelf aan het compileren gaat, waarom gebruik je dan nog de oude 1.6 versie en niet de veel nieuwere 1.7? ik weet neit wat voor distributie er op je server draait, maar het lijkt me dat er wel packages te vinden zijn met een fatsoenlijke svn client, die voor oa http support heeft! Source installs op een server zou ik zoveel mogelijk vermijden als ik jou was!

[GWTommy]

Inmiddels hebben we het opgelost. Het was inderdaad het ontbreken van neon. We hebben uitgevonden dat je de source van neon in de zelfde map moet zetten als waaruit je svn configured. In ieder geval bedankt voor het meedenken, ik had het zelf nooit opgelost.

@borft: uhm. Ja zoals ik al zei heb ik die handleiding van die plugin gevolgt. Niet het beste was er is misschien, maar voldoende voor het persoonlijke gebruik van mij. Ik zal binnenkort eens updaten. Ik draai overigens CentOS 5.5 met DirectAdmin.
Waarom geen source installs doen?

@Hero of Time: ik heb dat alleen gebruikt om te testen op een demoaccount. Overigens heeft er niemand toegang tot die logs behalve ik.

Ik heb ook niet geweldig veel verstand van dit alles, ik kan leuk wat dingen installeren, maar verder ook niet veel. Als het moeilijk wordt dan houdt het voor mij al op blijkt nu weer.

[Hero of Time]

Waarom geen source installs doen?

Omdat je zo alle updates zelf moet bijhouden, en niet door de distro maintainer. Je mist dan ook patches die ze doorvoeren. Het hele principe van Linux is dat je een centraal software systeem hebt. Door alles van source te installeren, haal je dat weg en krijg je security risico's omdat je kan vergeten om een package te updaten.

@Hero of Time: ik heb dat alleen gebruikt om te testen op een demoaccount. Overigens heeft er niemand toegang tot die logs behalve ik.

Toegang tot de logs, of de gehele server? Het heeft niet veel nodig om je bash_history uit te lezen. Simpelweg het bestand ~/.bash_history uitlezen of pijltje omhoog en je krijgt zo de hele geschiedenis met wat je hebt ingetypt.
Als ik niet anders kan dan een wachtwoord op de shell meegeven, dan log ik uit, weer in, en bewerk .bash_history om 't commando eruit te halen waar 't wachtwoord in staat.

[CyBeR]

Hero Of Time schreef op maandag 10 december 2012 @ 23:21:
[...]
Het hele principe van Linux is dat je een centraal software systeem hebt.

Whatnow?

[Hero of Time]

CyBeR schreef op maandag 10 december 2012 @ 23:50:
[...]


Whatnow?

Ah, screw it! Het was laat.