I've been learning how to use subversion and would just like someone to clarify whether or not my understanding is correct?Create a master repository at a given location (be it on a webserver or local).Add/import files into said repositoryCheckout a copy of the repository to work on (or specific files) to a working directory.Change/work/add certain files.Commit changes back to the master repository (With a note explaining changes, though changed files are noted, right?)Happy days...Assuming this is correct, I have a few questions.When working in a team, what happens when several people are working on one project and change the same files in different ways in one day? Surely when these changes are commit, they will overwrite each other? How should one go about testing their changes before commiting back to the master repo? Using PHP for my example, should the 'working' directory be in my xampp folder so I can test before commiting. Or should there be two master repo's on a webserver - one for testing and one for production?Apologies for the novice questions - there don't seem to be many tutorials or documentation that cover the basics - I understand the concept of source control for the sake of reverting, tracking changes and what not, but maybe need some clarification on how teams can use it effectively. If the idea is that one person should only ever be working on a single file at a time that just seems a bit... odd. If you're working with an MVC architecture, I can see the need for common views and controllers to be needed to work on by several people.
Version Control Workflow (Subversion)
version control;teamwork;svn
When working in a team, what happens when several people are working on one project and change the same files in different ways in one day?Surely when these changes are commit, they will overwrite each other? No, the one attempting to check in later must merge conflicting changes prior to committing his changes.How should one go about testing their changes before commiting back to the master repo?You should unit test your changes before committing them. Any further (integration / system / acceptance) tests are usually done on the committed version.Or should there be two master repo's on a webserver - one for testing and one for production?You should have one and only one source code repo per project. However, within that single repo, you can have different branches of the same codebase. And you can also deploy the actual version (or different versions) of your project to different environments. You should absolutely have (at least) one test environment next to your production server.