In this discussion, I would respectfully suggest a look at Bazaar: http://bazaar.canonical.com/en/ <http://bazaar.canonical.com/en/>
Part of the GNU Project, it is a very comprehensive tool that allows many workflows, including centralized (a la CVS/Subversion), gatekeeper, or distributed (like GIT). It is used by, among others, The Linux Foundation, Ubuntu, Debian, MySQL Integrates with LaunchPad, for creating a community with forums, bug tracking, etc… Here’s a nice overview: Ten reasons to switch to Bazaar http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html <http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html> > On Sep 28, 2017, at 05:29, Alexey Veretennikov > <alexey.veretenni...@gmail.com> wrote: > > Hi, > > I'm really having trouble to understand how did you find it difficult to find > information or concept guides. > > There is just an _awesome_ book available online: > https://git-scm.com/book/en/v2 <https://git-scm.com/book/en/v2> > which contains 99% of the stuff you need to know, including details on how > the internally git works, all concepts and explaining workflows. > There is an awesome speech by Linus as well which describes main concepts on > how it indented to be used: https://www.youtube.com/watch?v=4XpnKHJAok8 > <https://www.youtube.com/watch?v=4XpnKHJAok8> > > The github itself has a great tutorial and emphasize own workflow > (pull-requests). > > Also about working on your own, since the ability for git to work from > scratch without any servers etc just make it much easier for personal use > than svn and other vcs - i.e. you just archive whole directory and copy to > another pc etc and continue to work. > > Having say that, the usage of github or whatever other system is just a > maintainer preference: if he wants to make the contributions easier and reach > wider audience of contributors. So far github is the easiest and most widely > used repository storage and social network around open source projects (not > necessarily free software!). > > Dyalog for instance is already moving their auxulary libraries and tools to > github: https://github.com/dyalog/ <https://github.com/dyalog/> , in the move > to reach larger and younger audience of contributors and APL developers. > For example their new IDE, RIDE, is already there. > > P.S. On a humor note, about git: https://www.youtube.com/watch?v=CDeG4S-mJts > <https://www.youtube.com/watch?v=CDeG4S-mJts> > > Br, > /Alexey > > > > > > > > > > > 2017-09-28 5:10 GMT+02:00 David B. Lamkins <da...@lamkins.net > <mailto:da...@lamkins.net>>: > On Wed, Sep 27, 2017 at 12:00:08PM -0400, bug-apl-requ...@gnu.org > <mailto:bug-apl-requ...@gnu.org> wrote: > > From: Juergen Sauermann <juergen.sauerm...@t-online.de > > <mailto:juergen.sauerm...@t-online.de>> > > To: Elias Mårtenson <loke...@gmail.com <mailto:loke...@gmail.com>>, > > "bug-apl@gnu.org <mailto:bug-apl@gnu.org>" > > <bug-apl@gnu.org <mailto:bug-apl@gnu.org>> > > Subject: Re: [Bug-apl] Improved contribution workflow > > [... snip ...] > > As to Mercurial and git, I am really not a fan of them. Mercurial is kind of > > bearable because you can use it from SVN. > > But the way in which people work on github is, IMHO, horrible, even though > > they > > seem to be successful. This is probably > > due to my own lack of knowledge about git, but what I have seen so far is > > not > > motivating me to increase that knowledge. > > I can certainly appreciate the sentiment. I'd like to share my own experience > as a git user, FWIW. > > Until three years ago I had been a strong proponent of SVN. I understood as > much of the workflow as I needed. Really the only downside of SVN, for me, > was having to occasionally ping someone who had locked a needed file for too > long. > > Then I joined an R&D outfit that uses git on the engineering side. (The > business folks use SVN.) I have to say that my early experiences with git > were unpleasant, mainly due to the *huge* "surface area" of the toolkit and > the lack of a (IMO, at least) well-written concept guide. Mind you, there's > *tons* of "how to" posts and articles, some of which have been useful. But > the general approach is "here's how I did this" with little explanation > beyond the commands and arguments necessary to solve the problem... > > AIUI, one of the reasons for the depth of git is that it supports a plethora > of workflows. There are other factors, of course: the fact that git is a > distributed system and offers a bunch of "plumbing" for custom system > integration probably contributes to the bloat. The question you need to > answer -- and I don't think there's a one-size-fits-all perspective -- is how > you feel about the tradeoff between git's complexity and its capabilities. > > Again, AIUI: It's quite likely that if you're working on a project having > many contributors, then the project will have an established git workflow > with guidelines (or even requirements) as tohow to do common tasks. The most > difficult situation, I think, is to learn git on your own as a sole (or > principal) contributor, with only the man pages and the afforementioned > resources for deciphering git. > > GitHub takes away some of the complexity at the expense of hiding a lot of > the more clever bits of git. (I personally am not a fan of web UIs for > technical tasks.) The downside is that folks who learn only the GitHub (or > GitLab, or ...) interface tend to invent Rube Goldberg-like workflows or to > completely ignore, say, the notion of "upstream". Take a peek at > Arduino-related repos for a great example of this: I once had to (attempt to) > track down the source of some GPS code that originated for an Arduino shield; > there were multiple upstreams, each of which had tens or hundreds of forks. > The code that I was trying to identify, though, no longer existed. But these > are all git repos, no matter how many there are, right? Yeah, right. > Unfortunately, none of the "ease of use" of the web UI does much (if > anything) to inform its users regarding useful workflows. It turned out that > the owner of the "ancestral" upstream wiped and rewrote the repo for every > release; the early release that I needed to consult didn't exist anywhere... > > Personally, I'd advise taking at least a peek at git if the opportunity > presents itself. Regardless of whether you want to adopt git, you will > encounter useful projects that do present their assets as a git repo; you'd > be well-served to know some basic commands such as switching branches and > viewing the commit log. But I wouln't suggest jumping ship from a system with > which you're already comfortable. > > (That said, I *do* have a recommendation for a GNU Autotools replacement: > Meson and Ninja. I've begun to adopt that build toolchain for my personal and > work projects, and am quite pleased with what I've seen so far. For an > example of a small project built using Meson and Ninja, see the xs shell that > I maintain: <https://github.com/TieDyedDevil/XS > <https://github.com/TieDyedDevil/XS>>.) > > -- > "The chain which can be yanked is not the eternal chain." > -- G. Fitch > > --- Louis Chrétien lchret...@mac.com
