Hi,
> [...] better method to backup our main source code
This is definitely the advantage of source control systems as they manage backups and change history.
> an easier way to review coding changes
I would say that not always but as a rule. What personally I don't like in all modern non-locking source control systems is their automatic merge functionality. I treat it as a price that one must pay for the possibility to work on source code offline and in a distributed team. The problem is that merge not always works correctly.
In order to minimize the chances of this I use the following approach:
-- Check-in and commit to main branch often. You well may commit uncompleted and non-working code. Just make sure that this code will not prevent TestComplete from starting other tests due to some syntax errors and that this code is not called. If you have some syntax incompleteness (e.g. non-completed try/catch/finally structure), just comment it out, commit, uncomment and continue your work. Frequent commits minimize the chances of automatic merge problems;
-- Pull from remote main branch often to minimize the chances that automatic merge will fail and corrupt your code. (Note, that corruption may occur not on the syntax level, but on logical one, when the syntax of your source will remain correct, but the logic will be corrupted.) As an additional means of prevention of this problem, I have an additional folder with a copy of my sources (CopyTo utility is great to synchronize between this folder and the one with actual project sources). I first pull into this copy folder and use CopyTo utility along with WinMerge to review what was changed. I then pull into my actual working folder if everything seems to be fine. Otherwise I have a chance to clarify/correct incorrect changes/merge problems before they are introduced in my working code.
Yes, merge problems occur quite rare (in our test project, but quite often for developers), but my personal preference is to spend more time when pulling into my working test code than to spend time later trying to figure-out why tests stopped working.
And another thing that I don't like in modern source control systems (SCS) is that they use project (SCS project, not test or development project) as a minimal atomic entity to operate with. I mean that if, for example, you decided to keep product code, test code and documentation into one SCS project, you will not be able to get, say, just a documentation to work with. You will have to get to your local drive all development and test sources even if you never need them. (For example, if you are a technical writer.)
But in general, source control systems are a good means for versioned backup and more faster changes merge if used in a controlled manner.
