+1 on this approach, to me this is the obvious way that it should be
done. However, my opinion is not important, I'm not a contributor. :)
On 9/27/2017 8:37 PM, David Godfrey wrote:
Hi All
I have to agree with some of the other posters, why not use git as it
was intended?
Specifically I think the following makes sense.....
- Keep the multiple repositories, this helps when a company only
wants to make certain sets of libs available to it's staff
- Have a master repository that includes all other repositories as
submodules.
- Have branches that are matched to kicad versions. This allows
footprint changes in a version safe way.
- Use standard "git clone" (initial download) and "git pull" (update)
on the main repo which provides the entire set of available libs
without actually downloading the content for all libs.
- When a specific lib is needed, do similar to what we do now, and
use "git submodule update --init --recursive $submoduleName" to just
pull that specific submodule
- Allow the "main" library repo URI to be altered. This enables a
companies fork of the repo to be used.
- Allow the "main" library repo URI to be ANY valid git URI. That
means a repo on a local fileserver rather than a http server can be
used. Along with various security options etc.
- Add a fairly simple scripted tool that's run "on release" to
retrieve a README.md (an possibly a descriptor/index file) from each
actual library repo and update those within the "main" repo. This
removes the need to have the current case where manual edits are
required to keep the "main" repo in sync with what's available in the
individual lib's.
To add a new lib, it's then as simple as (from the main repo) doing
something like....
- "git submodule add $URI"
- "./scripts/update-library-indexes.sh"
- "git commit -a -m $'added new module "modulename"\nupdated all
module descriptions and index'"
- "git push"
All of the above allows the Main repo to be forked by a company (or
individual) and have their own custom repo's added very easily.
It even allows libraries to be easily excluded or replaced, all using
extremely well developed management tools.
On a side note, git submodules are stored in the main repository
basically as URI that includes a commit reference.
That means it's easy to specify a specific library version to include
in a specific branch/tag of the main repo.
As for the person that said "git isn't available for windows", sorry,
that's bunkum.
There are many many development environments out there that ONLY run
on windows that have git integration.
A quick google search for "git for windows" will show what you need
to know there.
Finally, wrapping git to duplicate the effective API that's currently
in use should be relatively trivial, resulting in virtually no code
changes required to KICAD it's self.
Assuming the existing functionality is cleanly wrapped by an API, the
only real change to KICAD would be the swapout of the module, and
addition of an easy way to change the URI
I know I haven't covered everything in this email, but it should be a
good outline for further discussion
_______________________________________________
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
