Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Small shop, few production servers, no test or development servers, all Win2k3 WEB based.

There is a need to keep versioned files on one of the machines. Is TortoiseSVN safe against exploitability, does it need extra hardening? Any known license problems, incompatibilities?

share|improve this question
"no test or development servers" Excuse me, but are you bloody serious? – sleske Apr 5 '12 at 7:22
@sleske: Not every shop is a multimillion company. There are startups with only 2-5 people working. – Coder Apr 5 '12 at 13:06
@Coder -- really don't matter. Staging don't have to be fancy -- an old desktop configured like your server is vastly better than nothing and doesn't require much in the way of resources. – Wyatt Barnett Apr 5 '12 at 15:59
@WyattBarnett: Exactly. In a pinch, the test server can even be a VM on a beefy desktop - the important point is to have a test environment, separate from dev and production. – sleske Apr 5 '12 at 18:41
Yeah, back when I was part-owner of a four-person startup, we still knew enough to have a test server and a CVS server. The cost was well worth it. – Ross Patterson Apr 8 '12 at 1:45
up vote 4 down vote accepted

If you are using SVN to deploy stuff then sure, why not? I can't count the amount of times being able to svn switch to the previous version of the app has saved our tails. It also opened up angles of letting people setup the push to production without access -- they commit, ops runs svn update.

Security-wise, it doesn't run anything that should be remotely exploitable and if you've got local exploit issues on the server then you probably need to rethink your security policy. The biggest issue if these are web apps is that the .svn folders on windows could potentially be read depending on server setup. Default IIS is fine -- it doesn't pass unknown extensions. But if you are, say, running tomcat as a web server, it will let people HTTP GET your svn-revprops and potentially bits of your source code, without some tuning. This is fixed by svn 1.7 as there are no longer .svn folders in every folder as 1.7 uses a central sqllite DB. So if you make the root folder higher than the webroot you are golden.

Or, if it helps you enough to be worth deploying to production than go for it understanding some caveats around file structures.

share|improve this answer
This is exactly the scenario I have in mind. Without actually SVN'ing the production folders, but only their mirrors. So that workflow is update->mirror_folder_w_svn->production_folder. – Coder Apr 5 '12 at 0:16
We tried that, didn't work so well -- tactical emergency updates weren't captured which was a big issue here. Finally just svn'd the folders and made sure things could not HTTP GET *.svn. With 1.7 it don't matter anyhow as you can push the .svn past the webroot with ease. – Wyatt Barnett Apr 5 '12 at 12:57
Don't forget svn export, which gives you a proper file hierarchy that isn't a "working copy". No worries about .svn contents then, 'cause it ain't there. – Ross Patterson Apr 8 '12 at 1:47
Well, the point is we wanted prod to be its own working copy so configuration tweaks could be versioned effectively. – Wyatt Barnett Apr 8 '12 at 11:28

It's not good practice. Every bit of software increases the scope for vulnerabilities. Generally, you should have as little software on your server as possible. Also, unless you're sending traffic over HTTP, it involves another port bring opened.

Licensing-wise, you're fine, it's open source.

I think a much better approach would be to version the files on the development machine before they are deployed to the server.

share|improve this answer
-1 He's asking about TortoiseSVN, which is a client, not a server. No additional ports, no additional network exposure. – Ross Patterson Apr 8 '12 at 1:49

I too agree that this is not good practice to have a repository on a production server. So you are going to version the files on the development machine and version the files on the production server? If you have that much time on your hands to do double the work, they aren't giving you enough work my friend. This is what the development machine is used for to develop the code, version the code, track changes, test changes, ..... THEN DEPLOY TO PRODUCTION machine. Everything on the production machine is working code if you use your development machine correctly.

share|improve this answer
You always have to version the files on both machines somehow...because they are physically separate machines. SVN is just one of many tools for doing that. It's not even a DVCS, so claiming there would be an additional repository on the prod machine is simply wrong. – Ixrec Jan 26 '15 at 22:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.