•Professional and Floating licenses only:
Multi-user editing is only supported with the Professional and Floating licenses for Help+Manual. All users accessing the project must be working with Professional or Floating licenses.

•Uncompressed XML save format only:
Projects must be saved in the uncompressed XML (.hmxp) format for multi-user editing to be possible. The compressed .hmxz format cannot be used because it is stored in a single file and it is necessary to access individual topic files for multi-user editing.

•All projects and sub-projects must also be saved as uncompressed XML:
If the project has any merged sub-projects they must all also be saved as uncompressed .hmxp projects. You cannot have any .hmxz sub-projects if you are going to use multi-user editing.

Help+Manual's integrated multi-user editing is only for users working on the same local network (LAN). If you wish to do multi-user editing remotely and offline (users in different geographical locations, also needing to edit without a network connection) you need to store a master copy of your project in a version control system. Then each user works on a linked copy of the project on their own computers, which they synchronize via the version control system's server. This provides all the advantages of direct remote editing, but each author is still working on their own local (but linked) copy rather than directly via an Internet connection.  

See Using Version Control Systems for instructions on getting Help+Manual set up to work with version control for remote editing.

Each remote user needs their own local copy of Help+Manual

Note that the remote authors will need their own copies of Help+Manual on their own computers to do this. This is possible with both the Professional and Floating license versions.

Supported version control systems

Out of the box, Help+Manual is already configured to support Subversion and Git. Both these systems are free and open source, and extremely mature and reliable. In addition to this, you can also configure additional scripts yourself to support any other version control system with a command line interface.

Basic procedure

With version control, authors can work on shared projects offline from any location. Each author downloads a local working copy of the project from the repository. This working copy is what you edit, but it remains linked to the "master" copy in the repository. Only changes need to be transferred in either direction. This makes the solution extremely efficient and also very robust -- you have none of the data integrity and speed nightmares involved in live editing via an open connection.

Almost all your work is done offline. You just need to synchronize with the server once before starting work, to get the latest changes from your colleagues, and once afterwards to add your new work to the server version.

Conflicts with other users' work

This process generally works even if two people have worked on the same topics. If they have edited different parts of the topics the changes are just merged silently, because there are no conflicts. If they have both edited the same text you get a dialog from the version control system asking you which versions of each change you want to keep ("mine" or "theirs"). Agreements between team members on which topics to work on can keep these conflicts to a minimum.

Full instructions

See Using Version Control Systems for instructions on getting Help+Manual set up to work with version control for remote editing.

Style standardization is a common problem in team projects: you generally don't want individual authors making arbitrary changes to the styles of your standard layout.

If you want to make sure that the same styles are used by everyone working on the project it's advisable to store the styles in a style repository project and link the repository to your documentation project. Then only give the team member responsible for layout access to the style repository so that only she or he can edit the project styles.

See Working with Style Repositories for instructions on how to set this up for your project.

The Refresh Project tool is for local multi-user editing without a version control system

This is a very important tool when you are working in Help+Manual's direct multi-user editing mode on your local network. It updates the display of the project and the TOC on your screen so that you can be sure that you are seeing the current version, including any changes made to the TOC by other users who may have moved, deleted or renamed TOC items.  

Refresh also updates the contents and lock state (read-only or read-write) of the current topic displayed in the editor.

Always use Refresh Project before making any changes that affect the TOC (renaming, moving, deleting and creating topics).

Always save your project directly after making changes that affect the TOC to make sure that there are no conflicts with other users' edits that you need to resolve.

See Creating, renaming, moving and deleting topics below for more details.

The Version Control tool is for projects managed in version control systems

When you are working on a local working copy of a project managed in a version control system you don't need to use the Refresh Project tool, because you are always the only person working on your local working copy.

Instead, you use the Version Control tool to merge your work with the master copy on the version control server. See Using Version Control Systems for full details.

For local multi-user editing, just store the project on a network or server drive where all authors have read/write access. (Save using the uncompressed HMXP format, otherwise this will not work!) Then all users open the same project and start editing as normal.

You will only notice a difference if you try to edit a topic that someone else has open – then you will get a message telling you that the topic is open and is not currently available. Help+Manual will never allow two different versions of the same topic to be created and it will never allow two users to edit the same topic at the same time. This applies even if you have not saved your project.

When you select a topic that another user is already working on you will see a red bar with a READ ONLY warning at the top of the editor screen and the topic will be grayed out in the TOC.

If another user starts editing the topic while you are viewing it you will not see the READ ONLY bar immediately. However, if you then try to edit the topic you will get a message telling you that the topic is now being worked on and then the READ ONLY bar will be displayed.

Custom display color for read-only topics:

You can set a custom color for displaying read-only topics in the TOC to make them easier to identify for you. Go to View > Program Options > Editor and change the setting for Display color for read-only TOC items.

Help+Manual never allows you to edit the content of topics being worked on by other users under any circumstances, even if you have not saved or refreshed your project.

However, when you make changes in the TOC in multi-user mode you are working on a local copy of the TOC. The changes are only written to the actual project file when you save the project. If another user has made changes to the same TOC entries you will have a conflict and a dialog will be displayed asking you to resolve the conflict – you must then decide which version of the changes to keep and which to discard.

User Refresh Project to avoid TOC conflicts:

To avoid conflicts you should always select Refresh Project in the Project tab before making any changes to the TOC. This will update your local copy of the TOC with the current main version.

Refresh also updates the contents and lock state (read-only or read-write) of the current topic displayed in the editor.

Creating new topics:

You can create new topics just as you would when you are working on a project on your own. New topics cannot conflict with changes made by other users so you can always create them. Of course, if you choose a topic ID/topic file name that conflicts with an existing topic you will not be allowed to create the topic.

Renaming, moving and deleting topics:

Always select Refresh Project before moving or deleting topics or renaming them in the TOC. This ensures that you are viewing the current version of the TOC in the main project file and prevents you having to resolve conflicts with your co-workers.

Once you have done this you can move and delete topics just as you would when you are working in single-user mode.

Even so, it is generally advisable to check with your colleagues before moving or deleting topics that others have also worked on! If in doubt make a copy of the topic with File > Save Topic to File in Project > Manage Topics before deleting it.

You can perform global search and replace operations normally when other users are working on the same project as you. You will be able to find terms in topics that other users are working on but you will not be able to replace them there until the other users save their work and stop editing the topics.

Your settings in the Configuration section of your project are not managed in the same way as your project content. Any changes you make here are made without warnings or locking. Anyone who makes changes here and saves the project will overwrite the current settings with the new settings.

When you are working in a team the Configuration section should be the responsibility of the project manager. Always check with your project manager or co-workers before changing anything in your project configuration!