>From what I understand, the target destination for the XML docs we create is the ./docs directory of the mainline repo, shown here:
http://svn.open-ils.org/trac/ILS/browser/trunk/docs There are a few problems with that, mainly that we no longer have a SVN committer in the group and that we would want to circulate, share and collaborate on the docs before pushing them into the one true repo anyway. This is a pretty common problem in open source software development, and it is the basic problem that distributed version control systems (DVCS) are designed to solve. I'll describe how we might use a DVCS in our case, which happens to be how I do my development every day anyway. So here is a git repository of Evergreen that I use, hosted at github: http://github.com/senator/OpenILS-Evergreen It looks similar to the trac/SVN view of the EG repo. You can switch to the branch I do doc work in called "docs_rock", at: http://github.com/senator/OpenILS-Evergreen/tree/docs_rock With a (free) account, you can create your own "fork" of the project directly via the web interface. Having installed/configured git on your local system, and with your github account (say, named "foobar"), the basic workflow might look like: # on github, click to fork a EG repo, then clone your fork for revision git clone [email protected]:foobar/OpenILS-Evergreen.git evergreen cd evergreen git checkout docs_rock # "set" a branch as active # add new files to ./docs, then git add <new_file_path> # and/or edit docs/1.6/...*.xml with whatever tools you want, then git commit -a # save all your changes in git # Done with some chunk of work (1 or more commits) git push origin docs_rock # Now everybody can see the changes on the website in your fork. # When ready, click "pull request" and the person you forked from # will be asked to propagate your changes upstream. There are many possible variations, but I think this would work. It's not magic, and I omitted installation and configuration. But notably, this process can be expanded an arbitrary number of times. That is, you needn't fork from the repository I'm working from, you might fork from the repo of the lead member for the chapter you are working on. And somebody else from you, etc. The great advantage is that instead of circulating email attachments, the editor(s) can get changes in the form of commit diffs directly from a version control system. This is just one approach. Really, any system that can get us out from separate firewalled institutional repos and into public space would be worth considering. --Joe
_______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
