On 8/17/2015 3:26 PM, Andy Peters wrote: > >> On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh <[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
Yep. This is pretty much what I do. I keep a few github entries for testing purposed but using a version control system is how I track libraries and projects. > _______________________________________________ > 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
