kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Using git directly in a plugin would also make the git library a
dependency to build KiCad which in not without it's own set of issues.

On 8/17/2015 3:39 PM, Matthew Beckler wrote:
> 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
> <mailto:devel@xxxxxxxxx>> wrote:
> 
> 
>     > On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> _______________________________________________
> 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
>