I like Author Care's golden rule: keep things simple and robust. This topic touches on the three basic ways of sharing help authoring tasks. In order of complexity:
1. Serial authoring. If you don't need to have both authors in the project at the same time, you can simply take turns working on the project. Just pass the files back and forth as needed. This is the most simple and robust approach.
2. Merging projects. If you need concurrent authoring, then, yes, this is a simpler and more robust approach than source control. However, this only works if you can partition your material and your work assignments into two or more clearly-delineated parts. Merging projects can be a great solution, but it doesn't fit all cases.
3. Source control. If multiple authors need concurrent access to the same material, then source control is the simplest answer.
Here are some tips and observations, based on my experience with RoboSource Control, in no particular order:
1. Source control works best on small-to-medium-sized projects. Large ones can be unstable.
2. Set it up to restrict file checkouts to one author only. Allowing two authors to work on a single topic simultaneously is bad.
3. If possible, try to work in different areas of the project that don't touch. Remember that a single change in one topic can ripple out to many related topics. (For example, if you change the filename of a topic, every link to that topic must be changed.) If someone else is working in one of those related topics, you will not be able to complete your initial change.
4. Make backup copies of your projects regularly, even though they are in source control.
5. Create an administrator account to be used just for that purpose. Don't use that account for regular authoring. Don't give everyone administrative privileges.
6. Designate one person as the administrator. Have at least one backup administrator. These will be the people who set up user accounts, override checkouts ("I need that file, and Joe is on vacation!"), resurrect old files, sort out source control conflicts, etc.
7. Check in files as soon as you're done with them. Don't leave them checked out longer than necessary.
8. If you have large projects, your virus scan utility can really degrade performance during certain operations, such as the initial "get" of project files. If this is the case, you might be able to configure your antivirus program to be friendlier to these source control activities.
9. The help authors should stay in close communication. Let each other know what you're doing, especially if you are doing something radical like moving folders around. Be ready to check something back in if someone else needs it.
10. Give a lot of thought to how your project is structured. Consider file structure, naming conventions, etc.
11. Some actions are more source control intensive than others. (Moving, deleting or renaming folders are biggies.) Your project is vulnerable while these changes are in progress. If something goes wrong before the process is complete, you can end up with a mess on your hands. For example, let's say there's a network glitch while you're moving a folder, interrupting your connection with source control. You can end up with RH thinking that the folder is in one place, while source control thinks it's in another. The result is broken links and missing files. Time for the administrator to step in and sort things out. This is almost never a problem for small projects. It becomes a real issue for large projects.
12. If you're getting close to a deadline, DO NOT pick that time to reorganize and rename files and folders.
13. Follow the correct procedure for adding a project to source control. Doing it wrong will really mess you up. Adding a project to RoboSource Control is easy. I can't speak for other source control solutions.
14. You might find it necessary to rebuild your cpd file more often than with non-source controlled projects.
15.Have I mentioned lately that you should back up your source files? 
HTH,
G
AdChoices