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

[Soulliere, Robert]

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.