[sword-devel] CrossWire and git
Tobias Klein
contact at tklein.info
Sun Nov 19 11:31:28 EST 2023
Hi Troy, Greg!
Any progress on this initiative? :)
Best regards,
Tobias
On 3/17/23 8:09 PM, Troy A. Griffitts wrote:
>
> I don't want this to turn into a debate.
>
> I agree, we need to move source control to git.
>
> I even mostly agree we should do most of our dev work on github for
> the visibility to draw other developers.
>
> To move forward with this:
>
> 1) I would actually need access to the github 'crosswire'
> organization, which I currently don't have.
>
> 2) I am happy to migrate our 27 repos there (yes, I was also surprised
> we have 27, but even these old ones would be nice to have on github
> for posterity).
> 3) After #2, I would love for Github experts to help me find a
> solution that effectively grant elevated access to individuals for
> merging PRs into our master repository without my approval FOR CERTAIN
> PARTS OF THE REPO they own or are trusted to approve.
>
> This #3 item had been the primary element holding us back from moving
> from SVN to git. If you are unaware, SVN has a very easy way to
> elevate permissions for accounts for parts of the repository. I don't
> want to have to approve all changes! I trust our pumpkin holders to
> care for their parts of the repository.
>
> We've discussed, in the past, submodules for handle this, but they do
> not handle this well. e.g., I want to grant Greg Hellings full write
> access to merge any PR which updates any of our cmake scripts in all
> folders everywhere. I don't know anything about cmake and Greg is an
> expert. I want him to be able to manage that build system without my
> oversight. I trust him. I do not want to grant Greg merge access for
> code that has anything to do with our C++ engine. He might be a great
> C++ programmer, but he hasn't expressed he wants that access or ever
> submitted C++ code for me to review and merge myself, so I want to
> protect Greg from accidentally merging in someone's PR which includes
> C++ engine code.
>
> In SVN this is easy. Attached is our SVN access file. Help me
> translate this workflow to Github. There must be some way to restrict
> merges based on the merging user and files modified in the PR. Or at
> least require a review by certain users bases on the files modified in
> the PR.
>
> Help me :)
>
> Troy
>
>
> On 3/17/23 11:24, Greg Hellings wrote:
>> Indeed. It's not a principled stand that I'm refusing to get
>> Subversion going. It's simply that it's too much work that I haven't
>> bothered and don't foresee doing so anytime soon.
>>
>> And, with no setup to automatically test the scripts in all the
>> environments they must support, it's not likely others are willing to
>> commit this on my behalf.
>>
>> --Greg
>>
>> On Sun, Mar 12, 2023, 09:42 Peter von Kaehne <refdoc at gmx.net> wrote:
>>
>> I think you misunderstood Greg.
>>
>> There is a long campaign and strong feeling to have the project
>> on Git but there is no agreement or movement to that. And it
>> seems Greg is pausing his contributions until that matter is
>> resolved.
>>
>> Peter
>>
>> Sent from my phone. Please forgive misspellings and weird
>> “corrections”
>>
>>> On 12 Mar 2023, at 15:51, ZdPo Ster <zdposter at gmail.com> wrote:
>>>
>>>
>>> I am sorry, but I did not get the point of your reply.
>>> I do not use subversion - I use git-svn as proposed several
>>> months ago on this forum. But current cmake configuration
>>> expects everybody to use subversion, which is wrong.
>>> These patches improve cmake build:
>>>
>>> * that will work also with git-svn
>>> * MSVC build
>>> * fix depreciated
>>>
>>> AFAIK it should cause no harm for other combinations, just
>>> improve current state.
>>>
>>> Zdenko
>>>
>>> On Thu, 9 Mar 2023 at 23:18, Greg Hellings
>>> <greg.hellings at gmail.com> wrote:
>>>
>>> I've never bothered to get Subversion setup on my local
>>> machine. Remembering the setup, plus my credentials, and how
>>> to use it is more labor than I've been willing to spend on
>>> this effort. If, in the future, I overcome that inertia then
>>> I'll happily test and apply this patch.
>>>
>>> --Greg
>>>
>>> On Sat, Feb 25, 2023 at 5:34 AM ZdPo Ster
>>> <zdposter at gmail.com> wrote:
>>>
>>> Any update on this (after 3.5 months)?
>>>
>>> Zdenko
>>>
>>> On Sat, 26 Nov 2022 at 21:53, Greg Hellings
>>> <greg.hellings at gmail.com> wrote:
>>>
>>> Thanks. I am not privy to the patches email inbox,
>>> so this mailing list is the way to reach me for
>>> CMake things. I'll review these when I have the
>>> opportunity.
>>>
>>> --Greg
>>>
>>> On Sat, Nov 26, 2022, 13:46 Peter von Kaehne
>>> <refdoc at gmx.net> wrote:
>>>
>>>
>>>> How to suggest improvements to the sword project?
>>>
>>>
>>> You did it the right way. It just is a bit
>>> on/off as a project. GHellings is the cmake
>>> pumpkin holder as far as I know. I bcc him on a
>>> different email address.
>>>
>>> Peter
>>>
>>>
>>>>
>>>> BR,
>>>>
>>>> Zdenko
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: *ZdPo Ster* <zdposter at gmail.com>
>>>> Date: Sun, 6 Nov 2022 at 22:22
>>>> Subject: cmake patches
>>>> To: <patches at crosswire.org>
>>>>
>>>>
>>>> Hello,
>>>>
>>>> please find 3 few patches related to cmake
>>>> build (tested on windows with MSVC 2019):
>>>>
>>>> 1. cmake_fix_deprecation.patch - cmake version
>>>> 3.23.2 produce depreciation warning for old
>>>> minimum version, co IMO it is time to
>>>> increase expected cmake version
>>>> 2. cmake_fix_msvc.patch - there is no "/O3"
>>>> options in current MSVC[1]
>>>> 3. cmake_git_svn.patch - I use git svn for
>>>> accessing code, but cmake produce error
>>>> because of missing svn executable. He is
>>>> patch that fixed it + code for detecting
>>>> svn revision (MYSVN_WC_REVISION) from git
>>>>
>>>> [1]
>>>> https://learn.microsoft.com/en-us/cpp/build/reference/o-options-optimize-code?view=msvc-160
>>>>
>>>> Zdenko
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your
>>>> settings at above page
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at
>>> above page
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at
>>> above page
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> _______________________________________________
>> sword-devel mailing list:sword-devel at crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20231119/c42f8871/attachment-0001.htm>
More information about the sword-devel
mailing list