We are all using git: We are in the official git repository: http://git.evergreen-ils.org/?p=Evergreen-DocBook.git;a=summary
compare the commits to our github repo which have been kept in tune: https://github.com/rsoulliere/Evergreen-DocBook/commits/master github is a git repository just in a particular location and gui interface. The repositories will be synchronized. I thought I explained that in the first part of my original email? We will continue to use git since it provides a few online editing features not available in the official Evergreen git repository location. The cool thing about repositories is that you can maintain several in several places and keep them synchronized. For community based projects, maintaining several repositories locations and keeping them synchronized might be a good approach as apposed to having one repository maintained by one person or organization. Regards, Robert Robert Soulliere, BA (Hons), MLIS Systems Librarian Mohawk College Library [email protected] Telephone: 905 575 1212 x3936 Fax: 905 575 2011 ________________________________________ From: [email protected] [[email protected]] On Behalf Of Lori Bowen Ayre [[email protected]] Sent: May 25, 2011 2:42 PM To: Documentation discussion for Evergreen software Subject: Re: [OPEN-ILS-DOCUMENTATION] DIG Repository Changes and Possible Approaches Robert, I see the issue. Git uses "branches" where Github uses "forks." Since Evergreen development just got moved over to Git, I assumed you were talking Git, not Github. My mistake. But it does raise the question...shouldn't DIG be using Git too? Lori On Wed, May 25, 2011 at 11:33 AM, Soulliere, Robert <[email protected]<mailto:[email protected]>> wrote: 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 [email protected]<mailto:[email protected]> Telephone: 905 575 1212 x3936<tel:905%20575%201212%20x3936> Fax: 905 575 2011<tel:905%20575%202011> ________________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] On Behalf Of Lori Bowen Ayre [[email protected]<mailto:[email protected]>] 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><http://www.galecia.com/> (707) 763-6869<tel:%28707%29%20763-6869> // [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> <mailto:[email protected]<mailto:[email protected]>>Specializing in open source ILS solutions, RFID, filtering, workflow optimization, and materials handling =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= On Wed, May 25, 2011 at 10:57 AM, Soulliere, Robert <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> 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 [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> Telephone: 905 575 1212 x3936<tel:905%20575%201212%20x3936><tel:905%20575%201212%20x3936> Fax: 905 575 2011<tel:905%20575%202011><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 [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> 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. _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected]<mailto:[email protected]> 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. _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
