kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 8/17/2015 3:26 PM, Andy Peters 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

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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>