kicad-developers team mailing list archive

[Blair Bonnett <blair.bonnett@xxxxxxxxx>]

On 18 August 2015 at 07:39, Matthew Beckler <matthew.beckler@xxxxxxxxx>
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 don't use the GitHub plugin, but mainly due to checkout time (i.e., lack
of local caching between KiCad instances) and the fact I don't always work
with an internet connection. So I keep local copies of what I need and
update when appropriate.

To me, the real useful thing about having a VCS plugin would be the ability
to enhance it with KiCad-specific addons. For example, think a visual diff
of changes to a library or a list of added components when browsing the
history of a schematic (assuming the plugin architecture gets extended to
eeschema when its overhauled post stable release).

> 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.

Finding a vendor-neutral API is unlikely. Even if you come up with
something that works for the major ones now, you'll run into someone who
uses something completely different...

A better solution is something that uses the Git protocol and thus can
interact with any Git repository, irrespective of what web interface it has.

A while ago I had a play around with libgit2 [1] and came up with a
proof-of-concept generic Git plugin. (Never shared as it was full of dodgy
assumptions, and I just wanted to see it was possible. Most of that code
would have to be refactored for an actual plugin). I only got basic
checkout working, but libgit2 offers support for authentication
(username/password and SSH), write ability, and all that sort of stuff.

One thing became clear: to use Git properly does require some changes to
the plugin architecture (and a couple of bits of the plugin policy). I have
a partially written blueprint for these changes; I haven't had time to
finish it off and post it due to recent teaching committments, but should
hopefully have time in the next week as the current term is almost over.

Once that proposal is sorted, I am happy to take the lead on implementing
the plugin, and would obviously welcome contributions and/or testing from
any other interested people.

Cheers
Blair

[1] https://libgit2.github.com/