Is it a good idea to install Subversion on a production server?
6 Answers
Let's define "Good idea" here. By the way, I'm making some assumptions here-- by svn you mean a client, not a source code repository. By production server, I'm assuming you mean a world-facing webserver or something similar.
svn itself probably won't hurt a production server. As Evan Anderson said, it's a userland process that doesn't do a lot of harm to the machine it's running on.
However, it's probably a really bad idea for a world-facing server to be able to read from your source tree. The machines that are hanging out there for the whole world to see have a fair higher probability of being compromised, and when that happens you don't really want the hacker to be able to check out your technical crown jewels.
I would have no qualms putting a svn client on a production server so long as it could only access a restricted set of data-- production configuration files could be one good use for this, and system administration scripts could be another.
In summary: I don't think installing svn on a production machine is a particularly good or bad idea-- if there's significant utility in it, then do it. I do, however, think it's a horrible idea for production servers to have access to the main source tree whether it's through svn or some other mechanism.
![](../../users/profiles/10501.webp)
- 652
- 1
- 5
- 7
Well, that depends. If by production server you mean installing it on your production web/database server, then probably not. If by production server you mean "a server that's reliable gets backed up", then yes.
I would avoid putting subversion on a server with other production apps, especially if it's web-accessible and doesn't need to be. Last thing you want is somebody hacking in there and stealing (or breaking/deleting) your source code.
![](../../users/profiles/4249.webp)
- 761
- 5
- 12
Umm-- if you need it. It's a user-land process, so it's not likely, regardless of server operating system, to radically affect server performance (i.e. crash OS, etc). In general, if you need something on a server you should install it. If you don't, you shouldn't. (I know that sounds a little silly, but you'd be surprised how many servers I find with HTTP / SMTP / etc server programs running on them for no reason.)
To decide which particular server computer to install it onto depends on a lot of factors-- capacity, security, accessiblity for the users who are using it, co-existance with other software that might need the same TCP ports, etc.
![](../../users/profiles/7200.webp)
- 141,071
- 19
- 191
- 328
-
1Definitely. We're going to need a lot more information to come up with real answers – Matt Simmons Jun 25 '09 at 19:06
I would have said SVN is the safest way of rolling out code to the production server.
A checkout confirms that you have copied over exactly the release you tested, there is no danger of accidentally copying the wrong or stale files, and then SVN will also confirm that you have the latest version.
![](../../users/profiles/4183.webp)
- 317
- 1
- 2
- 11
-
Usually an application would require some sort of build/deploy to actually work on a server. I wouldn't say it's a best practice to checkin build atrifacts back into the SVN repository. – Adam Oct 24 '10 at 00:29
-
I was assuming they meant a 'deploy' type build, ie. rolling out a website or server config rather than compiling an executable app. – Martin Beckett Nov 16 '10 at 19:19
If your goal is to use it to track changes to the system's configuration files which is a good idea but there are better tools for doing that.
Such as etckeeper. This tool does require that you have a repository somewhere that the server(s) can access.
![](../../users/profiles/5535.webp)
- 12,409
- 2
- 27
- 41
Installing the svn client shouldn't give you any trouble. It's stable userland software and will allow you to reduce the chance of errors on deployments.
I would suggest setting it to not store passwords though. Just in case someone breaks into your production server, it would be bad if that gave them free access to your source-code repository. Read this FAQ on how to disable password caching.
![](../../users/profiles/9082.webp)
- 7,438
- 6
- 39
- 62