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
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 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
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

--00163630ff2121b04d0482fbbaad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable