Hello

Thanks for your suggestion. In response to your arguments

break it down into smaller pieces: every file for each section

I agree that working with a 4000-line file can be unwieldy.

On the other hand, having to handle many small files (keep in mind we are talking about 37 distinct sections here, some of them with just 1-2 configs) can potentially be just as difficult to manage (e.g. finding the right file(s) to edit, replicating changes across multiple files).

reduce the chance that two people are working on the same files and generating conflict

Definitely not an issue in our case as 1. we have a small team; 2. documentation is not updated so frequently. Consequently it's very unlikely we'd see any conflicting updates and even if we did, as you pointed out, GIT would make resolving them easy.

Based on the above, I am not sure we would gain anything from such a split, and would recommend against it.

Are the instructions inside README still correct?

As far as I can tell, yes they are although it assumes that you have a properly setup and operational publican / docbook stack on your computer. Without further info, it's a bit difficult to give you any further details.

Then at least cut it into files of about 300 lines. When I was using Github's online editor, it was a pain in the part-of-the-body-you-name-it.

Anyway, do as you like. If the file size is smaller, I'll continue on the other bug. Otherwise, I will leave it to others.

Found a script to handle the splitting - is this what you had in mind ?

https://github.com/dregad/mantisbt/tree/docbook-split/docbook/Admin_Guide/en-US

I saw the "config" sub folder and those xml files. Yes, that's what I mean.

Does it compile well?

Does it compile well?

Yes it compiles OK.

Removed target version since this kind of changes should not appear on Changelog.