Hello,
I've got a svn checkout locally which I make changes to, once I commit them I go in and update my dev copy on the server.
My question is, what's the best way to get my files to my production site. I'm not much with linux commands, but I was thinking I could make a script that moves all files except .pyc and .svn files over to my production site? I don't really know what the best way is and I would like to hear from some experts on how to do it the right way.
I generally run directly from an svn checkout. Log in to the production server, update to the revision or tag that's been deemed worthy, restart the server and you're good to go.
This has the advantage that it forces you to make sure that everything is kept under version control because the production site comes straight out of the repository. You could obviously automate the deployment using something like Fabric if you wanted to.
Can't you keep a svn repo (maybe a R/O one) on your server and just have it svn up when needed? This way svn:ignore can take care of the business of ignoring certain files, &c.
If that's too cumbersome I would work by packaging up a "release" (set of files tested and working together) when ready (also tagging it for easy rollback in svn) -- say into a .tar.bz2 or .zip archive -- and send that to the server where it gets expanded. This way you have a good track of exactly what you released when and can deal with QA bug reports more easily; it will also be a lifesaver if you ever need to get into the branching business.
More generally, release engineering is an important and often-underrated discipline, and it's well worth reading up on it, even if right now you don't yet need to do anything complicated or highly structured in that field.
If you don't want to run your own repo server and are willing to spend some time learning mercurial or git, you can quickly setup a public or private repository at bitbucket or github.
The flow is: do your commits locally, push to online repo, login to your server, switch to the project and pull the changes. One rule of thumb is to never edit project code on the server, always commit locally and push, then pull to the server. local_settings.py is the only file that I edit directly on the server.
I use a pip requirements file for external dependencies, and its as easy as typing 'pip install --requirement external_apps.txt' to keep dependencies in sync. It also helps to use virtualenv to manage multiple projects (at the very least locally) and a fabric deployment script to simplify the deployment process.
Oh, and all VCS has a .ignore file where you can prevent files like local_settings.py and *.pyc files from appearing in your repo. Here is an example: http://tr.im/sXHF