[sword-devel] Using Git for Sword development?

[Troy A. Griffitts]

Thanks all for the discussion and helpful suggestions, and Greg, for giving a general summary. Just a couple quick comments:

I understand the familiarity of today's developers with git and do also appreciate the pull request functionality of tools like gitlab-- which we use on CrossWire and plan to use for all new projects, and as Greg has said, if I could easily grant full commit privileges to devs to certain parts of the repo, I would switch to git now. Partitioning into separate repos isn't always a reasonable solution (Greg's example with the make system comes to mind, with files scattered throughout each folder). The desire is sincerely not to restrict our current developers by staying with svn right now; on the contrary, it is to remove me as a bottleneck. I am happy for Greg to do whatever he wants with the cmake system. He understands it better than me. Peter has full commit access to our filters. We had a contributor and maintainer to our zModule drivers for a time. DM maintains many of our import tools. All contributors have write perms to our regression tests. We had volunteers to own our API docs for a while. Some longtime devs have full write access to our entire repo and can accept and apply patches from others. We all get patch emails when anyone commits (you can too by subscribing to sword-svn at crosswire.org) and as Peter mentioned earlier, many of us glance as commits after the fact-- I will glance at each commit and occasionally comment, but if I don't have time, I am happy for these individuals to move things along with the code they own responsibility for or have proved competent and demonstrated submissiveness to the owner of that portion of the repo. I wouldn't trust Peter contribiting the SWBuf code or the zModule drivers (nor should the previous maintainer of those drivers)-- no offense to Peter, I think he wouldn't want to make a change there without our review. I wouldn't dare touch the cmake build system without wanting Greg's input (unless I am simply adding a file to the strategy he's already produced). DM has unravelled most of the spaghetti dealing with all the craziness found in OSIS texts, for our primary import tool osis2mod and I would want him to approve any real changes I make there to the code he now owns responsibility for. New developers typically send me or another maintainer patch files, which allow us to comment and correct, teach and explain the intention behind the code and what we expect for changes to be accepted to the code on which we hold ownership responsibility. Then they eventually gain more and more write access to the repository directly. It lets me (and I hope others) sleep well at night and let's us leave for long periods of time when life gets busy, and doesn't block others here from committing to their responsible areas.

svn makes this super easy with an "access" file at the top of the repo which accepts patterns for write access for each user or usergroup.

I have hoped over the years that other projects would miss this function enough after their move from svn and someone would simply write a 1:1 drop in module for git with the same functionality-- and I do hunt around for it once in a while (I haven't looked lately). If we had this functionality, I would switch.

Do I really think this is keeping people from contributing to the engine? No. Anyone can "clone" our svn repo on GitHub or use the git-svn bridge right now, if they absolutely must use git. It's simple to do.

Using svn directly to modify and submit a patch with svn is as simple as:

svn checkout http://crosswire.org/svn/sword/trunk sword
cd sword
[Edit the sources]
svn diff > my-fix.patch

And attach your patch to a Jira ticket or email it to me.

scm discussions sometimes become a "religious" war because we really get to know and love our scm tools. git won't make me less anal when I review your patches. 🙂

Hope this helps other understand and possibly encourages someone to look around for an svn-access-like gitlab module or git hookset.

Much love 😉,

Troy

On February 9, 2020 12:13:01 AM MST, Tobias Klein <contact at tklein.info> wrote:
>Hi,
>
>I understand the reasoning about easily managing commit permissions.
>
>A way to achieve that flexibility with git (and the typical functions
>in 
>web-based Git repo browsers) is the following:
>- Put the more highly protected parts of the source tree in separate
>Git 
>repositories and link them in the master repo as "sub modules" (see 
>https://git-scm.com/book/en/v2/Git-Tools-Submodules). You can still 
>clone the whole source tree easily using "git clone
>--recurse-submodules".
>- Only give people developer access to the master repo, but not the 
>"protected" sub modules.
>- Generally: Protect the master branch(es) (then all contributions are 
>subject of review / merge request) and only give selected people 
>maintainer rights (the right to merge or push to master).
>
>This is how we do it at work. It works well! :)
>
>Best regards,
>Tobias
>
>On 2/9/20 5:08 AM, Greg Hellings wrote:
>>
>>
>> On Sat, Feb 8, 2020 at 1:49 PM Tobias Klein <contact at tklein.info 
>> <mailto:contact at tklein.info>> wrote:
>>
>>     Hi,
>>
>>     Have you guys been thinking about migrating the Sword sources to
>Git?
>>
>>
>> We have this discussion every year.
>>
>>     I think this would be an enabler for better collaboration,
>>     considering
>>     the merge capabilities of Git and for example the nice merge/pull
>>     request based review functionalities in GitLab (or GitHub).
>>
>>
>> Every time, this gets lots of people voting "yes"!
>>
>> Every time the short answer is the same:
>> Troy doesn't want it moved. So it is not going to get moved.
>>
>> The longer answer also remains the same:
>> Git has no simple method, in a similar vein to SVN, to allow Troy to 
>> easily manage commit rights to particular portions of the repository.
>
>> He wants to keep tight control over who can commit where (e.g. I can 
>> commit anywhere under the "bindings" or "cmake" directories or to any
>
>> file named "CMakeLists.txt", but nowhere else in the repo) and does 
>> not believe the code review process in git front-ends is sufficient 
>> for this. Writing a git hook to ensure this is not difficult, but
>also 
>> not completely trivial. In SVN it's a very simple matter. It's not a 
>> lack of familiarity with git (Troy develops Bishop within a git 
>> repository and seems a relatively intelligent software developer 
>> overall). It's literally this one missing feature, at least that's
>the 
>> one impediment he's spoken about in the past.
>>
>> So:
>> * Would git greatly increase the ability of people to contribute to 
>> Sword? Yes
>> * Would Troy host Sword's canonical repository somewhere like Github?
>
>> Probably not
>> * Is Sword going to move to git without, at the very least, a
>solution 
>> to this directory write problem? Nope
>> * Is that problem surmountable? Yes, but no one has stepped up and 
>> implemented it in a githook, and SVN is working fine in Troy's view
>to 
>> not encourage him to write it himself.
>>
>> --Greg
>>
>>
>>     Best regards,
>>     Tobias
>>
>>
>>     _______________________________________________
>>     sword-devel mailing list: sword-devel at crosswire.org
>>     <mailto:sword-devel at crosswire.org>
>>     http://www.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://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20200209/08e89622/attachment-0001.html>