Evergreen DokuWiki

First of all, you are welcome to email the Documentation Listserv (open-ils-documentation@list.georgialibraries.org) with problems you find in the documentation. However, we welcome you to participate in the process of improving things. Below are various ways you can contribute your time and skills.

We use Git for version control on documentation. The official repository is housed on the Evergreen git server git.evergreen-ils.org.

Note: Changes to the official repository are processed into HTML, PDF and ePub daily at 1pm and 11pm. (see http://docs.evergreen-ils.org/)

• Send your documentation changes in any format to the Documentation Interest Group (DIG) email list: open-ils-documentation@list.georgialibraries.org
• Valuable contributions include:
  • Telling us about anything that seems wrong
  • Corrections of typos
  • Corrected step-by-step instructions
  • Updated screenshots
  • Telling us of missing sections
  • Etc.
• Please include the following information in your email:
  • URL of the documentation web page that needs to be updated
  • The part of the web page you are referring to (e.g. section heading, paragraph number, a nearby phrase, etc.)

1. Login to GitHub (or create a free account)
2. Find the relevant file in the GitHub repository
   • Look around until you find the content (note: the directories are mostly logically similar to the online docs table of contents sections, but may require some searching around)
3. Click the pencil ("Edit this file") icon to edit the file in your browser
4. If you are creating a new file, click the plus symbol that displays to the right of file path.Type in the file name.
5. Make your changes, using correct AsciiDoc format.
6. Test that your AsciiDoc syntax is correct. This is not required for simple typo corrections.
   • PREVIEW as HTML: Any file on GitHub with the extension of ".adoc" should auto-display the HTML version of the file when previewed or saved. Then you can proofread your document and look for anything strange.
7. Type a message describing your change
8. Click the "Propose file change" button
9. Click the green "Create pull request" button
10. One of the developers will review your change and send you feedback

A variation of this workflow is described in this YouTube video.

This workflow is primarily for the few DIG members with permission to push to the master repository. If you do not have permission yet, you can start the request process by contacting the Git Admins group gitadmin@evergreen-ils.org. You can also push to another public repository, such as the Evergreen working repository or another host such as GitHub. Then email the DIG email list open-ils-documentation@list.georgialibraries.org with the location of your repository so they can pull your changes into master.

Use these procedures on Linux, Mac OS X, or GitBash on Windows.

First time only

1. Type git clone git://git.evergreen-ils.org/Evergreen.git to create an initial copy of the repository on your machine. This will clone the whole Evergreen repository, which contains the docs directory where all the documentation lives.
2. cd Evergreen/docs - Moves to the new directory you just cloned.

If you aren't able to push to the documentation folder, try these troubleshooting steps:

1. Open the ../.git/config file.
2. Check the url listed for remote named origin. It should be git@git.evergreen-ils.org:Evergreen.git. Specifically, make sure that:
   • The first occurrence of the word git is followed by the @ symbol, not ://
   • Evergreen is preceded by a :, not a /
   • The url ends with the .git file extension

Every time

1. git fetch --all
2. git checkout master
3. git pull - Pulls the most recent changes into your cloned version. This avoids merging issues and errors when "pushing" your changes to the remote repository.
4. Make changes to files, remove files, add new files

After you've made your changes, make sure that your documentation is included in the appropriate manual(s). To do this, make sure that there is a include::path/to/documentation.adoc[] statement in the appropriate root_*.adoc file (e.g. root_circulation.adoc for the circulation manual).

Then test building the various output formats. The following examples use the Circulation manual, but you will want the filename root_circulation.adoc to match the manual you are trying to test.

1. asciidoc root_circulation.adoc - Converts AsciiDoc text files to HTML format. This will give you errors if the AsciiDoc format is incorrect. Once it succeeds, verify that the HTML appears as you expect. Finally, delete the output files (e.g. rm *.html) to prevent them from being committed along with your AsciiDoc files.
2. a2x --fop root_circulation.adoc - Converts AsciiDoc text files to PDF format. Verify that the PDF appears as you expect. Finally, delete the output files (e.g. rm *.pdf) to prevent them from being committed along with your AsciiDoc files.
3. a2x --format=epub root_circulation.adoc - Converts AsciiDoc text files to ePub format. Once it succeeds, delete the output files (e.g. rm *.epub) to prevent them from being committed along with your AsciiDoc files.

When you are satisfied with your changes, commit the files.

1. git add - Tells git that you have added or edited files on your local machine and want to add them into the repository. The changes are not committed yet.
2. git status - Check to make sure that you are committing the correct files.
3. git commit -s OR git commit -sm "Docs: [what you changed]" - Commits changes to the repository. You must provide a note on what you changed, beginning with the phrase "Docs: ". If you use the shorter form, a text editor will open (usually vim) where you will write your change note. (Using the -m switch is a time-saver if your note is short) To commit all changes, use git commit ..
4. git push
5. git log -3 - Shows the 3 most recent commits. Check to make sure that your commit:
   • has a clear message that describes your change
   • has a signoff

After you have committed to master

1. git checkout [BRANCH] - you will probably also want to add your change to the documentation for all relevant versions. For example, if you are documenting a feature that was added to version 3.2, you will want to add it to the 3.2 documentation. Release branches are in the form rel_3_2, so for our example, you would type git checkout rel_3_2.
2. git pull - if this branch has changed since the last time you ran this command.
3. git cherry-pick [NUMBER OF COMMIT] - if you didn't note the number of the commit, run git checkout master; git log -3 to find it. Then be sure to return to this branch with git checkout [BRANCH].
4. git push

If you are committing a change that somebody else made:

1. git commit -s --author="Firstname Lastname <email@domain.com>"
2. Add a commit message that begins with "Docs:"

If you try to push your change, but somebody has changed the Evergreen in the repo in the meantime, you will get this error:

error: failed to push some refs to 'https://git.evergreen-ils.org/REPOSITORY.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

If this happens, you just have to run git pull –rebase, which should bring in the latest changes and put your commit on top. After this, you can just repeat your git push command.

These procedures are recommended if you are not comfortable with the command line.

First time only

1. Install one of these recommended programs: http://git-scm.com/downloads/guis
2. Start the program. Look for something like "Clone Existing Repository". In "Source", put git://git.evergreen-ils.org/Evergreen.git; leave "Target" blank to use the default path, or enter something else (it creates a new directory, so don't use one that exists already). Click Clone.

Every time

1. Start your graphical git tool. Open the Evergreen repository you cloned earlier.
2. Select: Remote -> Fetch From -> origin
3. Select: Merge -> Local Merge, and click Merge to pull the most recent changes into your cloned version. This avoids merging issues and errors when "pushing" your changes to the remote repository.
4. Use a good text editor to make changes to files or create new files.
5. Test that your AsciiDoc syntax is correct. A quick way to do this is by creating a Gist and naming it filename.adoc. Then you can proofread your document and look for anything strange.
6. Press F5 (or select Commit -> Rescan) to view the changes you have made. Files will display under Unstaged Changes (red). Click a file to see color-coded changes in the pane to the right.
7. With your changed files highlighted, click "Stage Changed" to tell Git you want to add the changes to the repository. The changes are not committed yet. Files will display under the green "Staged Changes" section.
8. To commit (a step that confirms your intention to make changes to the public repository), first type a note on what you changed in the "Commit Message" box. A note is mandatory. Then click the "Commit" button.
9. Finally, push your changes to the remote repository by clicking "Push." A dialog box will open with the default settings (source branch master, remote origin). Click "Push". If you are one of the few DIG members with permission to push to the master repository, you will need to enter your SSL passphrase. If you do not have permission yet, you can start the request process by contacting the Git Admins group gitadmin@evergreen-ils.org. You can also push to another public repository, such as the Evergreen working repository or another host such as GitHub. Then email the DIG email list open-ils-documentation@list.georgialibraries.org with the location of your repository so they can pull your changes into master.
10. If you get "Error: Command Failed," changes may have been made by someone else since you last pulled a copy of the master file. The text in the box will say that "non-fast-forward updates were rejected." Click Close, do a fetch and merge (or a pull, which does both), and push again.
11. Once your changes are pushed to master, you should see them show up in the master repository.