Ubuntu 7.04, Subversion and Apache2

b4u

Golden Member
Nov 8, 2002
1,380
2
81
Hi,

I'm currently getting to grips into a linux setup. I'm new at linux, so I'm learning how it works.

For a start, I installed a test box with Ububtu 7.04 Server. Since I want to learn how to do everything, I downloaded Java from Sun, and Apache Geronimo J2EE web server.

Now the system is working good. At startup, Geronimo goes up listening in port 8080.

Now I want to install subversion, as I would like to do some version control.

That's where some confusion just appears.

I read somewhere else that is was a practice to install an apache2 server to redirect requests. I saw some tutorial on installing Tomcat, that would install to servers, the Tomcat and the Apache2 server.

Is this correct, or am I confused? So why would I, for instance, install an Apache server when I already have a Geronimo server working? What would be the benefict?

Am asking this because I just installed svn, using the command "sudo apt-get install subversion", when I can also see in the tutorial that I should use "sudo apt-get install apache2 subversion libapache2-svn". So once again, an apache2 to reach subversion?

I didn't install it that way, and on restart, I can see with "netstat -natp" that I have no other port listening besides my ssh port 22 connection.

So this just confuses me. How is subversion control accessible through a client? Must I have an apache2 server? Again I arrive at question #1 ... the reason why we have to install apache2 to redirect stuff.

Thanks
 

drag

Elite Member
Jul 4, 2002
8,708
0
0
If you provide a link to the tutorial your talking about it would be helpful.

I don't know much about subversion, I never used it except to download source code time to time. From a quick google there are 3 ways of accessing a subversion repository...
1. SVN over SSH
2. SVN over Apache
3. SVNServe

Depending on what sort of client you want to use you'd use one or more of those.

Anyways, the new sexiness is GIT for version control. It's what all the cool kids are using. :p
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
Unless Geronimo can load Apache2 modules or has an equivalent to the mod_dav_svn and mod_authz_svn modules then you probably do need Apache2. Back when I setup svn I just used Apache2 because it's prepackaged and virtually 'just worked'.
 

Brazen

Diamond Member
Jul 14, 2000
4,259
0
0
I set up a Subversion server and just use the svn protocol to access it. It's the easiest and fastest way to do it. You only need Apache if you want better authentication options or if you want to encrypt the svn traffic through https.

I don't know what document you used, but starting with ZERO svn knowledge (though quite a bit of linux knowledge) this is the only documentation I needed from start to finish (for the server part anyway), then used TortoiseSVN from a Windows machine for the client (I did also read a lot of the documentation on the TortoiseSVN site, but that was more on how to USE svn as an end-user rather than how to set up the server).

Also, the guide gives /path/to/repo/project as an example for where to create the repo, but just FYI to keep things "linuxy" your repo should probably go under /var/lib/svn (or possibly /var/svn ?)

EDIT: By the way, I would also STRONGLY suggest you use Dapper Server instead of Feisty (stick with the LTS releases on a server).

edit: ok, after glancing back over that document, I guess it didn't tell everything. If you want svnserver to start up automatically, you run it from xinetd. Just google for 'svn xinetd' and you should get some help.
 

kamper

Diamond Member
Mar 18, 2003
5,513
0
0
You'll want to be reading this: http://svnbook.red-bean.com/

Apache integration is sort of the favourite of the svn developers and you find it on the biggest public repositories. Frankly, I think the added complexity is silly, especially when you're learning. In my personal network, I just run svnserve as a daemon that is available to all hosts but I'd think twice before exposing that to the internet. There are also a pile of ssh integration scenarios that are quite interesting. If I ever need remote access, I just use my current setup with ssh tunneling.