Large parallel commits

Question

This may sound like a very basic question to some of you but I am new to subversion and would like your advice on this question:

How should I handle a large commit that took several days of work to code if person B also modified and committed his changes before me? His commit concerned the same files as me.

To sum up, here is the workflow:

• Commit A based on rev.1, not pushed yet
• Commit B based on rev.0, already pushed, creating rev.2

Is it risky to push commit A given the amount of code that has been changed between rev.1 and rev.2?

Sorry for the noob question but I just want to avoid breaking the project's code. Worst case scenario, I rewrite my part of the code, checking out the repo to rev.2 before.

Answer 1

SVN won't allow you to do a commit if it detects that any of the files you want to commit were committed by someone else since the last time you updated. Instead, it will error out with an error message telling you that you need to do an "svn update" before committing. When you do the "svn update", the other person's changes will be integrated into your local files without any data loss, and once you've verified that everything still works, you can go ahead and do your own commit.

This isn't too risky; the worst-case scenario would be if the other guy modified a lot of the same lines in the same files that you did; in that case, the "svn update" will result in conflicts and you will have to go into the conflicted files, manually edit them to choose which lines you want to keep and which to get rid of (the files will contain both your version and the other guy's version of these lines, and they will be clearly marked in the file, so this isn't as bad as it sounds), and then do an "svn resolved" on the conflicted files to let SVN know that you've taken care of the conflicts. After that you can compile, test, and commit your code as usual.