Help & Manual 6.1 Released

[Tim Green]

Help & Manual 6.1 has just been released. This is a free update for all Help & Manual 6 users. Visit this pages for information and to download:

Change log and information page
Download page

Please note that active SubVersion integration is not included in this release. This is taking longer than expected and we wanted to get the other changes out now rather than waiting with everything until the SubVersion support was ready.

[Kevin_MBS]

[quote]What would be nice.. if the new releases.. asked or pulled in the previous definitions. I have to go thru and set up shortcuts and such every time i upgrade.[/quote]
They do. If you install on top of your current version then all your settings should remain unchanged.

[Mathias Johansson]

Hi Tim,

We have just purchased/start to use H&M and everyone loves the ease of use.

However the only part we miss was the SVN support which should have been in he 6.1 release which has been postponed to a later date.

Do you have any idea when?
Does it exist in beta form?

Since we just started to use the tools its feels ankward to learn to work in a certain way and then need to change the way of work.

Best Regards
Mathias

[Tim Green]

Hi Mathias,

We are working very hard on the active SVN support and we are going to release it as soon as possible. It has been delayed because it has turned out that we need to almost completely rewrite the SVN diffing component to work properly with Help & Manual, which is a great deal of unexpected extra work. However, you can already start working with SVN with your projects now, you just need to perform a couple of extra steps manually. There are two ways of doing this. Which one you choose will depend mainly on how comfortable your individual users are with checking items in and out manually in Tortoise. For general work, option B is probably preferable.

Option A: Each user has a local copy, SVN and Tortoise handle merging

1) You maintain your project in your SVN repository and each user checks out a local copy on their machines using Tortoise.

2) Before starting work each day, each author performs an update with Tortoise to make sure that any changes made by other authors are merged into their local copy. Similarly, at the end of work each author commits their work to the repository using the Tortoise Commit tool.

If there are any conflicts these can be resolved with Tortoise and communication with the other authors. But 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.

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.

Option B: Check out one local copy that all users work on, HM handles multi-user

1) You maintain your project in your SVN repository but you only create ONE local copy, which must be stored on a network drive to which all users have read/write access.

IMPORTANT: This must be a Windows share, or a Linux/Unix share with full support for Windows file locking with the SMB protocol.

2) At the beginning of the working session the project leader checks out the entire project to the local copy.

3) The users all edit this copy at the same time. Help & Manual manages multi-user editing automatically, locking topics for access by other users while one user is editing it. See the chapter on Multi-User Editing in the Help & Manual help for details.

4) At the end of the editing session the project leader checks the project back into the SVN repository to update the changes.

[Mathias Johansson]

Thanks for the answer.

Option B works as a gap filler for out eniroment!

Best Regards
Mathias

[Chris Gooch]

Tim,

I'd just like to give you some hopefully helpful feedback on svn use. We are using tortoise more or less as you say for option 'A' - i.e., we try and remember to update regularly and not get out of sync. One thing we did was make the svn server email us whenever there is a commit, so others know that an update might be wise.

Despite this, we do from time to time run into issues with conflicts when doing a commit or update when somebody has edited without noticing they should have done an update first, or we just overlapped. This mostly causes a problem with things like tables, it seems to me - edits in chunks of text seem to merge well enough using tortoise's merge, but sorting out the conflicting lines of xml in a table, even if both edits were fairly minor, can be a headache. So full integration would be great.

We have people working remotely in different cities and countries - will this scenario be covered? (i.e., any svn integration that is essentially a wrapper around your option B won't work for us, as we don't have a network drive we can use - short of putting it up on a cloud server or something. Will each H&M instance using the svn client be integrated so that it marks a topic as changed on the server without you having to do anything? Or will the benefit mostly be the diffing / merging when updating or committing?

regards,
Chris.

[Tim Green]

Hi Chris,

Thanks for the feedback!

Yes, text in complex structures like tables can be troublesome, but this will definitely be covered in the active integration. I can't swear to it at the moment, but I'm pretty sure we're also going to get a lock-modify-unlock model, also for remote editing. So even in the checked-out local copies users would get a read-only warning on topics that are currently being edited by any other user linked to the same central repository, in the same way that they do with the current lock-modify-unlock model used with Visual SourceSafe.

However, there will also be a diffing model, and this is precisely what has delayed the integration of SVN past the original 6.1 release target. Because of things like the table issue it has proved to be necessary to rewrite and extend the diffing modules very extensively to deal with Help & Manual's XML smoothly and efficiently. So the work that is currently under way is to deal with precisely the kinds of issues you are running up against here.

[Chris Gooch]

Tim - thanks for that. So it sounds like we could use the lock-modify-unlock model normally (when people are working online), and still have a good xml-aware merging tool for sorting out any conflicts that should occur if people have worked off-line (while travelling, etc.)? If so then that sounds perfect, just what we need. I must admit I personally didn't see a great need for GUI integration of svn originally, but not all members of our team agreed with me, plus it turns out that the awkwardness of diffing/merging using tortoises tools when the diff is in a table makes it a pain (and we have lots of tables unfortunately). So we're looking forward to it!

cheers, Chris.

[Tim Green]

Hi Chris,

To be honest I don't have the details on the SVN implementation yet but we'll be posting them as soon as they become available.