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 <[email protected] > <mailto:[email protected]>> wrote: > > > > On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh <[email protected] > <mailto:[email protected]>> 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 : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
