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 [email protected]) 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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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: [email protected]
>> <mailto:[email protected]>
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
>> _______________________________________________
>> sword-devel mailing list: [email protected]
>> 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.
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
