[OPEN-ILS-DOCUMENTATION] DIG Repository Changes and Possible Approaches

Wed May 25 14:33:31 EDT 2011

Well I guess I was confused by the github GUI.

If you go to the github repository here:
https://github.com/rsoulliere/Evergreen-DocBook/

Notice the icon  on the far right (looks like two arrows pointing down). Hovering on it indicates that it is called "Forks".

When you click on it you will get to a page "The Evergreen-DocBook network graph" with various lines indicating "remote branches" we have set up for testing.

Also calling them forks based on this: http://help.github.com/fork-a-repo/

which seems to indicated that forks can be merged.

I guess the difference as I understand it is that a fork is when another person "forks" the repo under another account versus a branch which is created by the same person.

 In our case the forks/branches would be maintained by others and merged into the main repository as apposed to a branch under "master" maintained by the same person.

For example here are two "forks" or "remote branches" of our documentation:

https://github.com/hcethatsme/Evergreen-DocBook
https://github.com/ysuarez/Evergreen-DocBook

Regards,
Robert.

Robert Soulliere, BA (Hons), MLIS
Systems Librarian
Mohawk College Library
robert.soulliere at mohawkcollege.ca
Telephone: 905 575 1212 x3936
Fax: 905 575 2011
________________________________________
From: open-ils-documentation-bounces at list.georgialibraries.org [open-ils-documentation-bounces at list.georgialibraries.org] On Behalf Of Lori Bowen Ayre [lori.ayre at galecia.com]
Sent: May 25, 2011 2:14 PM
To: Documentation discussion for Evergreen software
Subject: Re: [OPEN-ILS-DOCUMENTATION] DIG Repository Changes and Possible       Approaches

Robert,

I think you mean to use the term "branch" where you are saying "fork."  Branches in git are generally what get merged into the main trunk (as I understand it).  A fork is something that veers off on its own and doesn't make it back into trunk.

And that approach (as your described in your second scenario, assuming you mean "branch" is a pretty standard workflow.  Again....as I understand it and my understanding is limited.

Lori

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=
Lori Bowen Ayre // Library Technology Consultant
The Galecia Group // www.galecia.com<http://www.galecia.com/>
(707) 763-6869 // Lori.Ayre at galecia.com<mailto:Lori.Ayre at galecia.com>

<mailto:Lori.Ayre at galecia.com>Specializing in open source ILS solutions, RFID, filtering,
workflow optimization, and materials handling
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

On Wed, May 25, 2011 at 10:57 AM, Soulliere, Robert <robert.soulliere at mohawkcollege.ca<mailto:robert.soulliere at mohawkcollege.ca>> wrote:
Hi DIGers,

This is just to note that the master home repository for the documentation has officially changed to (as of last week):
http://git.evergreen-ils.org/?p=Evergreen-DocBook.git;a=summary

However, the github repository  will be synchronized with the master repository:
https://github.com/rsoulliere/Evergreen-DocBook/

We will continue to work with the github repository to take advantage of some of its features especially the web interface which allows online updates to the repository.

This brings me to a question about approaches with 2 possibilities:

1) Centralized repository approach where users work in the main repository with some forking taking place on an individual request basis. -- kind of how it works now.

2) Decentralized "forked" teams approach where we have official github forks based on content parts of the documentation. E.g. Someone maintains a fork for the Admin team and another person maintains a fork for the OPAC team, etc... These forks will then be merged  into the main repository at http://git.evergreen-ils.org/?p=Evergreen-DocBook.git and the main github fork at https://github.com/rsoulliere/Evergreen-DocBook/. These merges will take place at least daily if not several times a day.
Now it is possible for individuals to create their own forks and send pull requests to me to merge into the main repository. However, my goal here is to not have a lot of manual pull requests but to have an automated merging of the trusted team forks into the main repository on a schedule. The other advantage of these team forks is that it could, perhaps, encourage collaboration among teams working on various parts of the documentation. Then there is the argument that this approach takes fuller advantage of the git "decentralized version control system" features.
This second approach does not affect the procedures for contributing documentation. It really only effects "where" they will contribute.

Any ideas questions, comments, other suggestions?

Regards,
Robert

Robert Soulliere, BA (Hons), MLIS
Systems Librarian
Mohawk College Library
robert.soulliere at mohawkcollege.ca<mailto:robert.soulliere at mohawkcollege.ca>
Telephone: 905 575 1212 x3936<tel:905%20575%201212%20x3936>
Fax: 905 575 2011<tel:905%20575%202011>

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.
_______________________________________________
OPEN-ILS-DOCUMENTATION mailing list
OPEN-ILS-DOCUMENTATION at list.georgialibraries.org<mailto:OPEN-ILS-DOCUMENTATION at list.georgialibraries.org>
http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation

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.