No subject

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 com=
mitter in the group and that we would want to circulate, share and collabor=
ate 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 happen=
s 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 th=
e 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 direct=
ly via the web interface.  Having installed/configured git on your local sy=
stem, and with your github account (say, named "foobar"), the basic workflo=
w might look like:

# on github, click to fork a EG repo, then clone your fork for revision
git clone git at github.com: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 pro=
cess can be expanded an arbitrary number of times.  That is, you needn't fo=
rk from the repository I'm working from, you might fork from the repo of th=
e lead member for the chapter you are working on.  And somebody else from y=
ou, etc.

The great advantage is that instead of circulating email attachments, the e=
ditor(s) can get changes in the form of commit diffs directly from a versio=
n control system.  This is just one approach.  Really, any system that can =
get us out from separate firewalled institutional repos and into public spa=
ce would be worth considering.

--Joe

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message.  If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited.  If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.