When I’m working on my application with SVN do I want to download my entire site from the repository and work on it the way I have been? Or do I download individual files? If I do it that way, how do I test the application?
Typically, you would have 3 areas of development. You develop locally, on your machine, and do your testing there. This is also where your checked out repository (working directory) will reside.
As you make changes, you commit them to your development server. This is kind of a staging area, and this is where you make sure everything will work perfectly in an environment that mirrors your production environment.
Finally, when all is done with a particular feature/application, etc. you will jump on your production server and perform an export of your SVN repository - bringing all of those new files over to the production server.
Also when do I “commit” my changes that I made?
When you are fearful that what you just completed may be lost, or break something. In general: commit when you are done working for the day, complete a feature, or complete a major milestone when working on a feature.
For instance, let’s say we’re allowing users to upload an avatar. I would commit when I finished the models, one for the avatar and altering the user model (to support avatars) and I would commit after completing the controller and view. Depending on what you are working on this may be more often or less often.
Is commiting finalizing the changes and adding them back to the repository?
Committing just sets a “marker” - it is a point in the development of your application that you can consistently return to. Using our Avatar example above (committing after the model changes and another commit after feature completion) we could easily roll our code back to when avatars didn’t exist, or if we felt the model was solid but the implementation side of things (controller/view) were weak, had bugs, or presented security issues, we could just roll back to before they existed.
A very common way of developing applications is to use “branches.” For instance, let’s say adding in avatar support is a small part of completing updating user profiles and making them more powerful/customizable. We would probably want to start a whole new branch for these changes. We would make hundreds of code changes and commits, rolling forward and backward, making sure everything is good within this branch. Once we know that this branch is final - it’s good to go, we would then merge that branch back into the trunk - which is the master, final version, of the code.
After a bit of testing in development environment - off it goes to production.
By using branches, you allow other work to continue within the trunk (or other branches), without the possibility of messing up what you are working on. When you go to merge, you’ll be presented with any “collissions” that occur and will than have to fix those. But, that’s a lot better than working on one file for a few days, trying to commit only to find out someone changed it, so you update your local copy, and then learn everything you’ve been working on is completely different now.
