tags:

views:

242

answers:

6

So,

At my job we use svn to manage our source code, but when deploying, we do an svn export and rsync that tree with the code that is on production. This is the way it has been done since I started (it is my first programming job) and how we continue to do things.

I've started to work on my own personal projects outside of work and still use svn to to manage my code - however, instead of syncing an export with the tree on the server, I simply do a checkout on the server and when I roll new code I just svn up. This seems simpler to me.

Are there good reasons not to use svn on a production machine? A security risk that I'm overlooking?

+2  A: 

I think Svn for deployment is ok. It's easy if your server has the client installed, and it has less steps than export and rsync.

The only problems I can see is some cheap hosting providers who don't support that, and that the svn client may store the account you used to check out the code, possibly allowing someone else access.

Jani Hartikainen
+1  A: 

1st thought: In the event of compromise, your attacker now has access to your source code as well.

Autocracy
Unlike when using `svn export` and `rsync` ;-)
Michael Krelin - hacker
I think he means "to the source code *management system*"
UncleZeiv
Depends on if he's using a compiled language. Also, note Paul Biggar's answer.
Autocracy
Autocracy, right, but we were talking about `svn export+rsync` vs. `svn checkout/update`. And `.svn` directories are handled by http server. Naturally, using a compiled language with binary rollouts is better in all respects, but beyond the scope of present discussion.
Michael Krelin - hacker
It's a security *consideration.* In this case, it may be mitigated, but that doesn't mean it should be dismissed off-hand. The .svn may be handled correctly by the HTTP server, but if it's not thought about, it may not be handled.
Autocracy
+4  A: 

A svn checkout is ~2x the size of the exported data, because the .svn folders contain data used to revert in case you make a mistake. Exporting doesn't create the .svn folders, and therefore can use less space.

Billy ONeal
meh, code space is really irrelevant these days. Checking out 20 MB instead of 10? oh no, how will my 320 GB Striped and Mirrored server HDD ever handle that?
Neil N
I'm not saying it's a good reason. I'm saying it's a possible reason.
Billy ONeal
+4  A: 

I can think of a couple of issues:

  • checkout on the server will create unecessary .svn directories there
  • to checkout on the server, the user needs both SVN and server access rights

These are off the top of my head - I'm sure there are more.

anon
+1 + `svn checkout` of the large codebase may introduce unacceptable delay.
Michael Krelin - hacker
+ having to have `svn` access credentials on the production machine.
Michael Krelin - hacker
Of course, the first reason goes away if you do an export on the server. I think the second point is the more important.
anon
you could create a user with read-only rights, and you could also avoid storing them on the server... just provide the credentials every time.
UncleZeiv
UncleZeiv, yes, you can minimize "damage," but you can also avoid it altogether ;-)
Michael Krelin - hacker
+2  A: 
  • extra load on the server
  • changes to your prod environment imply disruption to what should be unrelated aspects of your dev infrastructure, and vice versa. Problems with one disrupts the other.
  • challenges managing roles and permissions. Neil's example of needing both svn and server accounts is one example. Managing appropriate file system access controls is another (should the whole team have write permission to the production directories?).

In a nutshell, using svn on the server introduces a tighter coupling between dev and prod, which causes issues that aren't so different from tight coupling between different parts of code.

Darryl
A: 

You'll be making your source code available on the web in the .svn directories, which might be a problem.

This is exactly what we do with phc, and you can access the .svn files as a result. But since its open-source, that doesn't matter.

You could fix that with .htaccess files, of course.

Paul Biggar