Version Control Workflow (Subversion)

Question

I've been learning how to use subversion and would just like someone to clarify whether or not my understanding is correct?

1. Create a master repository at a given location (be it on a webserver or local).
2. Add/import files into said repository
3. Checkout a copy of the repository to work on (or specific files) to a working directory.
4. Change/work/add certain files.
5. Commit changes back to the master repository (With a note explaining changes, though changed files are noted, right?)
6. 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.

Answer 1

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.

Answer 2

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?

You have a conflict and you have to merge. Generally the second to commit has to do the merging.

Surely when these changes are commit, they will overwrite each other?

No, there will be an error messages and you will have to merge the different changes.

How should one go about testing their changes before commiting back to the master repo?

Continuous testing and a good set of unit tests.

Never commit known broken code.

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?

This is called branching.

Answer 3

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?

I must to re-phrase and slightly fix previous answers. Second commit will be not allowed automagically, committer has to update his modified WC (working copy) and merge (automatically or by hand - it depends) incoming changes with own. After merge he'll can commit.

when these changes are commit, they will overwrite each other?

If they intersect at the row level, then win only one variation (handmade merge result), if they touch different strings - repo will store 2 (or more) revisions with all changes

How should one go about testing their changes before commiting back to the master repo?

Same way as it was before SCM. QA and unit-test not related to version-control in common. And yes, developer can commit broken unfinished code of repo - it's a question of usage policy, not used SCM

Using PHP for my example, should the 'working' directory be in my xampp folder so I can test before commiting.

You have (at least) 2 choices:

• Yes, site root can be root of (additional) working copy, which (WC) have to be updated after each commit (read "post-commit hooks in SVN") - this way you have to test always latest fresh full code. But don't forget to protect .svn folders inside site-tree from spy and spiders
• Another solution is to use svn export to extract code from repo and place it on site. Less security, but more headache - if wc update can handle all changes in source-tree (move-delete), export only place current snapshot, thus - all deletes|renames|moves will be performed only partially, without cleaning old data - you'll have delete *.*; (x)copy *.* and this means additional time and resources

Or should there be two "master repo's" on a webserver

You can't use repo content directly anyway, even with FSFS you'll not see inside repo your stored objects