Am a little confused about how subversion model works. So say me and my colleague have the same file checked out but we're working in different places of the file would subversion just merge both changes?
Most of the time we'll be working with php and xml files, does that mean we should use subversions default model and not lock files?
Right, if you're working on different areas of the same file then Subversion can sort it out. Only when you work on the same (or very near) area of the file, will you need to deal with merge conflicts.
The situation is as follows:
The results depends on the changes. If the changes are in different sections of the code, the merge is done automatically.
If changes overlap Subversion tells you the file is conflicted und you have to decide, whether:
After you resolved the conflict, you have to commit the file again, to make your changes permanent.
As Frank said.
There's also great article in this topic. Maybe it is focused on agile version control, but also should help you understand how the svn works: http://www.infoq.com/articles/agile-version-control
Yes, subversion concurrent edition model will definitively work for you.
If you are both editing the same file, the scenario will be the following:
For the first one that commits the file, the behavior is straightforward. The file is update in the repository.
For the second one, the process is a little bit different he will be guided by the ool.
When trying to commit, he will be asked to update the file first because the repository has been updated in the mean time. The update will proceed to an automatic merge where possible and identify possible conflicts.
When the local copy has been merged, conflicts if any should be solved manually and a round of testing should be performed to confirm that your changes are not conflicting.
When the local code is ok, a commit will update the repository (at that time the repository consider that your local code was based on the latest version.