← Back to team overview

kicad-developers team mailing list archive

Re: [Patch] Add gitlab support to github plugin

 

Hi Andy,

What you say makes sense. For the purposes of this discussion, git vs svn
is irrelevant. I also prefer to keep all my kicad libraries in an svn/git
repository and just have to remember to "svn up" / "git pull" on each
machine I use. As you said, this requires no support from KiCad except for
being able to access libraries on a local filesystem.

I think this may be another instance where the desires of experienced power
users differ from those just getting started with KiCad.

I like what Wayne said above; it's really nice to resolve the difficulties
of distributing huge packages containing the libraries, and to ensure that
users don't have to deal with outdated library packages in the
distributions. Makes sense.

Getting back to the question about adding gitlab support to the github
plugin, does anyone know if there is any vendor-neutral git API that could
be used on any publicly-accessible git repository? Perhaps it wouldn't be
too difficult to refactor the github plugin into a generic git plugin? I
will try to look into the github plugin to see how it works.

Cheers,
Matthew

On Mon, Aug 17, 2015 at 2:26 PM, Andy Peters <devel@xxxxxxxxx> wrote:

>
> > On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
> >
> > If someone wants to write a git plugin, I'm sure some users would find
> > it useful.  I'm not sure most users will want to learn git to maintain
> > their footprint libraries even though it's a good thing.  The gihub
> > server implementation was written because KiCad's libraries are
> > maintained on github which gives you direct access to the latest and
> > greatest footprint libraries provide by the project.  This also means
> > that we do not need to package a snapshot of the footprint libraries.
> > Of course you can always keep a local clone of these and/or your own
> > libraries on your computer and access them directly by configuring your
> > footprint library table accordingly.  That really is the power of the
> > footprint library table.  You can store footprints on a central server
> > or you can store them locally on your system or store them both places.
> > This is entirely up to the user.
>
> I’m going to throw this out there. Please note that I am not a git user,
> and every time I’ve had to look at git I ask myself, “Who thought this was
> a good idea?”
>
> My kicad libraries are kept in a Subversion repository. On all of my
> machines, Kicad uses checked-out working copies of the libraries. Those
> working copies reside in the standard directories (~/Library/Application
> Support/kicad/ on my Macs), but of course they can live anywhere I choose.
> The pcbnew libraries are all the .pretty type. If I make any changes to the
> libraries, I commit the changes back to the repo in the standard way. The
> main thing I have to remember is that I have to do an svn update on the
> other machines to pull in those changes. This works perfectly well for
> teams of engineers using the shared libraries. (Prior to introducing their
> “vaults,” Altium integrated some method of using Subversion to store shared
> libraries, and it works basically the same way as my standalone method.)
>
> The beauty of this is that *none of the above requires Kicad to know
> anything at all about Subversion.* The working copies could well be from
> some other source-code control system.
>
> A lot of firmware- and software-development IDEs have to have built-in
> support for SCC-du-jour, and it makes no sense. Windows users have a
> perfectly excellent Subversion client in TortoiseSVN. I’ve been using svnX
> on the Mac for years. There are other excellent SCC clients one can use.
> And the command line isn’t all that hard, either. So all of this effort to
> build in support for one particular SCC system seems to me wholly
> unnecessary.
>
> Just my two cents. I understand why the Kicad team built in git support
> for the footprint libraries — what Wayne says above perfectly expresses it.
> And of course I am for anything that gives the newbies a head start on
> learning the software. But I honestly don’t think that advanced users,
> especially those who have other SCC systems up and running, will see it as
> a particular advantage.
>
> -a
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References