Reasons / against using svn for deployment?

Question

So,

In my work, we use svn to manage our source code, but when deployed, we export svn and rsync, which is a tree with code that is in production. This has been the case since I started (this is my first programming task) and how we continue to do something.

I started working on my personal projects outside of work and still use svn to manage my code. However, instead of synchronizing the export with the tree on the server, I just do a check on the server and when I download the new code, I just sleep. It seems simpler to me.

Are there any good reasons not to use svn on a production machine? The security risk that I miss?

Answer 1

I can think of a few issues:

• checking on the server will create unnecessary .svn directories there
• To check on the server, the user needs access rights to the SVN and server.

It’s not in my head - I’m sure there are more of them.

Answer 2

The svn check is ~ 2x the size of the exported data, because the .svn folders contain the data used to return in case of an error. Export does not create .svn folders and therefore can use less space.

Answer 3

I think Svn for deployment is fine. This is easy if a client is installed on your server and it has fewer steps than export and rsync.

The only problems I see are some cheap hosting providers that do not support this, and that the svn client can store the account you used to verify the code, possibly allowing someone access.

Answer 4

• additional loading on the server
• Changes in your prod environment mean failing as to what should be an unrelated aspect of your dev infrastructure, and vice versa. Problems with one are disturbed by others.
• Call management roles and permissions. An example is the use of both svn and server accounts. Managing the appropriate file system controls is different (if the entire team has permission to write to production directories?).

In short, using svn on the server introduces a closer connection between dev and prod, which causes problems that are not so different from the hard connection between different parts of the code.

Answer 5

1st thought: in the event of a compromise, your attacker now has access to your source code.

Answer 6

You will create your Internet source code in .svn directories, which can be a problem.

This is exactly what we are doing with phc and you can access the .svn files . But with its open source, it doesn't matter.

You can fix this with .htaccess files, of course.

Answer 7

If you do not want to have .svn folders in your live directory live and still use the update instead of exporting because it is fast, just check your www repository in another folder called predeployfolder, for example.

Each time you want to transfer the current version of the HEAD repository to your current www folder, do a quick update of svn to the predeployfolder and then re-sync between the predeployfolder folder and your live www folder and specify that the .svn files should be closed as follows way:

rsync -az --eclude="*.svn*" predeployfolder wwwlivefolder