When you're using version control passively it is okay for all users to work on one working copy at the same time, provided this does not cause problems for your version control system . Even so, you should check with the person responsible for managing your version control system before doing this.

This method creates a single working copy of the project in a location where all members of the team have editing access. It is the best choice if the team members don't have any experience managing local copies of version control projects themselves.

The working copy is linked to the master copy in the version control repository. You check out the working copy from the repository at the beginning of the editing session and everyone works on it in the same way that they would work on a multi-user project in Help+Manual without VCS support. At the end of the working session the updated project is then checked back in to the VCS repository.

Important warning:
Direct remote editing (e.g. via a VPN connection) should NOT be used with this method. The risk of damage to the working copy in the event of a network connection failure is too high. See Remote editing for the single-copy method below for instructions.

Procedure

The following steps should be performed by the person responsible for managing your version control system, using the VCS' own management tools.

1.Save your project in uncompressed XML format (HMXP) and load the entire project into your version control system's repository.

2.Create a working copy of the project linked to the version in the repository. This copy should be in a network location accessible to all the authors on the team who plan to work on the project. It should be on a Windows server or a Linux/Unix server with full support for the SMB protocol and Windows file locking.

3.At the beginning of the working session check out the entire working copy (all topics).

4.All authors can then open and work on the project at the same time, using the standard multi-user editing procedures you would use for a project that is not linked to a VCS.

5.At the end of the working session the administrator then checks the local copy back into the source control repository.

We don't recommend trying to participate in a multi-user editing session on a single-copy VCS project directly via a remote connection (for example a VPN connection). Although it is possible, the risk of problems caused by losing the connection is not really acceptable. The way to solve this problem is to log in to computer on the local network where the VCS is stored using Windows Remote Desktop or a third-partly solution like LogMeIn or GoToMyPC. This is also the safest and most efficient way to do any remote editing, not just in multi-user editing scenarios.

Benefits of Remote Access:

When you use Remote Desktop you are actually working on the computer in the location you are accessing. Help+Manual is running on that computer, not on your computer, and all the data stays in that location. (This can also be a security benefit for sensitive data.) Your computer is just a terminal, and in addition to the user interface, only what you type is transferred via the network connection. This greatly reduces bandwidth, and modern Remote Access solutions are mature and reliable. Often, it is possible to use them reliably via a normal Internet connection, even from a public hotspot.

If the connection is lost while you are working via Remote Desktop there is no risk at all. The computer in the location you are accessing continues to run normally, and when you log in again you can continue working exactly where you left off. Nothing can be lost – it has no more effect on the computer than getting up for a coffee break and then coming back.

What you need:

Current versions of Windows come with a Remote Access system called Microsoft Remote Desktop, which works very well. It can be a little tricky to set up for private use, but if you have a system administrator they will be able to configure it for you easily. Third-party solutions like LogMeIn and GoToMyPC eliminate the configuration hassles and "just work", but they cost money.

Once you have got the Remote Access set up, you just make sure that you can log in to a computer with a licensed copy of Help+Manual on it in the location you want to access. This computer must be either running, or you need to be able to turn it on remotely when you want to start work. Once you have got this set up, logging in to this computer is just like working at that computer in the office.

This option provides more control and flexibility, allowing users to work on their local copies "offline". However, it is only possible with version control systems that support merging, like Subversion and Team Foundation Server. Also, this method should only be used if the participating users are willing to manage their local copies themselves.

Procedure:

1.The project administrator adds a copy of your project to your version control system repository using the system's own tools.

2.Each user uses their local version control system tools to create a local working copy of the project on their own computer.

3.Before starting work each day, each user synchronizes their working copy with the repository to make sure that any changes made by other authors are merged into their local copy.

4.At the end of work each author synchronizes with the repository again, to add their changes. If there are any conflicts they are managed with the version control system's own merging and diffing tools.

If there are clear agreements within the team as to who is responsible for which parts of the project there should not be any major problems with conflicts.

The only thing you need to be a little careful about when working like this is that there should be a clear agreement as to who is responsible for making project configuration changes. The main project file where all this is stored is also XML and will thus also merge well, but managing conflicts here can sometimes be a little trickier. Changes to the Table of Contents should always be merged as soon as possible.

Remote editing with the multi-copy method is not a problem because all the editing is done offline anyway. This is effectively the same as working with Subversion or Team Foundation Server with active support from Help+Manual.

Users only need to ensure that they have access to the repository on the server often enough so that their local copy does not get out of synch with the master copy in the repository. Most modern version control systems have options for remote access via the Internet and VPN connections.