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