[OPEN-ILS-DEV] Git repository management best practice question

Wed May 18 10:50:27 EDT 2011

As it stands we can push to a github repo automatically whenever  
someone pushes a change to git.evergreen-ils.org, and are doing so for  
Evergreen, Open-ILS, and SIPServer now. See  
https://github.com/evergreen-library-system/ for those three.

Thus, workflow is "fork on github, pull request, someone pushes to  
git.evergreen-ils.org, github gets a copy within about 5 seconds".

Github shouldn't see any real difference between pushing directly to  
it and pushing to git.evergreen-ils.org as a result. So I believe you  
have the basic workflow down.

Thomas Berezansky
Merrimack Valley Library Consortium

Quoting "Soulliere, Robert" <robert.soulliere at mohawkcollege.ca>:

> Thanks for the guidance Thomas.
>
> I had a few follow up questions:
>
> I understand how the branching works when using the same remote  
> repository in github but had a followup question regarding  
> "auto-update
> github whenever a push happens on git.evergreen-ils.org".
> So is the github master branch update triggered as soon as something  
> is pushed into the git.evergreen-ils.org  repository or is it  
> updated on a schedule (e.g. hourly cron job)?
>
> Would the suggested work flow model look like this:
>
> A) Users update their github branches and request changes are pulled  
> into master repository on git.evergreen-ils.org: Docbook.
>
> B) master repository maintainers pull changes into   
> git.evergreen-ils.org: Docbook repository. (done manually upon  
> request?)
>
> C) github master is auto updated from git.evergreen-ils.org:Docbook repo.
>
> D) Users synchronize their branches with github master to get latest  
> changes. (responsibility of contributors to keep up to date)
>
> Thanks,
> 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-dev-bounces at list.georgialibraries.org  
> [open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Thomas  
> Berezansky [tsbere at mvlc.org]
> Sent: May 16, 2011 3:55 PM
> To: open-ils-dev at list.georgialibraries.org
> Subject: Re: [OPEN-ILS-DEV] Git repository management best practice question
>
> Someone else may be replying as I do on this...
>
> We currently have rigged several of the other repos to auto-update
> github whenever a push happens on git.evergreen-ils.org. Doing so for
> the documentation would work. People then branch off, make changes,
> and someone with access to the core repo can then pull and merge them.
>
> No changes would be pushed to the github copy, only to branches off of
> it (which is how I think you should be doing it on github already).
> Any changes pushed to the core github repo would be overwritten
> automatically in this model whenever a change was pushed to the
> evergreen-ils.org repo.
>
> Thomas Berezansky
> Merrimack Valley Library Consortium
>
>
> Quoting "Soulliere, Robert" <robert.soulliere at mohawkcollege.ca>:
>
>> Hi,
>>
>> Now that we have added the documentation repository to the official
>> Evergreen git site I had a question as to the best way to maintain
>> the github site as an option for contributors.
>>
>> The reason why I would like to keep it as an option is because it
>> provides some editing options (browser based edits) which are not
>> available in the new repository (that I am aware of).
>>
>> I think I have the technicals on pulling from the github site and
>> merging into the official repository, but I think problems could
>> occur in the following scenario:
>>
>> User A edits file A and pushes changes to official repository.
>> User B edits file A and pushes changes to the github repository at
>> the same time.
>> When the github changes are merged with the official repository, a
>> conflict will occur and one of the user's changes will be lost.
>>
>> I think these kinds of conflicts could occur even when users are
>> working on the same repository (separate cloned instances), but the
>> problem would be compounded with 2 separate repositories.
>>
>> I wonder if:
>>
>> a) This potential problem should be solved with work flow
>> policies/rules so that users are only working on specific ares of
>> the documentation and do not edit the same file at the same time? Do
>> developers have such policies for code edits?
>>
>> b)  It is advisable that we only use the official repository and
>> eliminate the github repository as an option to reduce complexity
>> and potential confusion?
>>
>> c)  There is a git command sequence I am not thinking of which will
>> remove the potential conflicts?
>>
>>
>> Thanks for your advice,
>>
>> 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-dev-bounces at list.georgialibraries.org
>> [open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Galen
>> Charlton [gmc at esilibrary.com]
>> Sent: May 16, 2011 8:22 AM
>> To: Evergreen Development Discussion List
>> Subject: Re: [OPEN-ILS-DEV] Git status
>>
>> Hi,
>>
>> On May 14, 2011, at 3:02 PM, Galen Charlton wrote:
>>> [2] Create separate repositories of parts of ILS-Contrib, in
>>> particular the website.  I'm open to suggestions about how current
>>> users of ILS-Contrib would like to have separate repositories
>>> organized.
>>
>> This has been done for the website and Conifer's contribs.  I'm
>> pleased to also report that DIG's repository is now hosted on
>> git.evergreen-ils.org as well.
>>
>> Regards,
>>
>> Galen
>> --
>> Galen Charlton
>> VP, Data Services
>> Equinox Software, Inc. / Your Library's Guide to Open Source
>> email:  gmc at esilibrary.com
>> direct: +1 352-215-7548
>> skype:  gmcharlt
>> web:    http://www.esilibrary.com/
>> Supporting Koha and Evergreen: http://koha-community.org &
>> http://evergreen-ils.org
>>
>>
>> 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.
>>
>
>
>
> 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.
>