<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">Thanks all for the discussion and helpful suggestions, and Greg, for giving a general summary. Just a couple quick comments:<br><br>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@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.<br><br>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.<br><br>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.<br><br>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.<br><br>Using svn directly to modify and submit a patch with svn is as simple as:<br><br>svn checkout <a href="http://crosswire.org/svn/sword/trunk">http://crosswire.org/svn/sword/trunk</a> sword<br>cd sword<br>[Edit the sources]<br>svn diff > my-fix.patch<br><br>And attach your patch to a Jira ticket or email it to me.<br><br>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. 🙂<br><br>Hope this helps other understand and possibly encourages someone to look around for an svn-access-like gitlab module or git hookset.<br><br>Much love 😉,<br><br>Troy<br><br><div class="gmail_quote">On February 9, 2020 12:13:01 AM MST, Tobias Klein <contact@tklein.info> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<p>Hi,</p>
<p>I understand the reasoning about easily managing commit
permissions.</p>
<p>A way to achieve that flexibility with git (and the typical
functions in web-based Git repo browsers) is the following:<br>
- 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 <a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a>).
You can still clone the whole source tree easily using "git clone
--recurse-submodules".<br>
- Only give people developer access to the master repo, but not
the "protected" sub modules.<br>
- 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).<br>
<br>
This is how we do it at work. It works well! :)<br>
<br>
Best regards,<br>
Tobias<br>
</p>
<div class="moz-cite-prefix">On 2/9/20 5:08 AM, Greg Hellings wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAHxvOVJn0S-=O0crm1tWSFT4deAt6egjtxvFE=_d=-d8fDw6WA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Feb 8, 2020 at 1:49
PM Tobias Klein <<a href="mailto:contact@tklein.info" moz-do-not-send="true">contact@tklein.info</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Have you guys been thinking about migrating the Sword
sources to Git?<br>
</blockquote>
<div><br>
</div>
<div>We have this discussion every year.</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
I think this would be an enabler for better collaboration,
considering <br>
the merge capabilities of Git and for example the nice
merge/pull <br>
request based review functionalities in GitLab (or GitHub).<br>
</blockquote>
<div><br>
</div>
<div>Every time, this gets lots of people voting "yes"!</div>
<div><br>
</div>
<div>Every time the short answer is the same:</div>
<div>Troy doesn't want it moved. So it is not going to get
moved.</div>
<div><br>
</div>
<div>The longer answer also remains the same:</div>
<div>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.</div>
<div><br>
</div>
<div>So:</div>
<div>* Would git greatly increase the ability of people to
contribute to Sword? Yes</div>
<div>* Would Troy host Sword's canonical repository somewhere
like Github? Probably not</div>
<div>* Is Sword going to move to git without, at the very
least, a solution to this directory write problem? Nope</div>
<div>* 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.</div>
<div><br>
</div>
<div>--Greg<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Best regards,<br>
Tobias<br>
<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank" moz-do-not-send="true">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above
page<br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
</blockquote>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>