mysql?? wth is that ... i think you meant mariaDB ? right? here is a google cache of projects using bazaar web page - the original site didn't come up form me
On Thu, 28 Sep 2017 08:41:57 -0400 Louis Chrétien <lchret...@mac.com> wrote: > 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 > > > >
