Collaboration Feature (request)

Do you have a proposal that doesn’t involve “magic”?

The ECAD tool we use supports collaboration, but it still needs scripts written in house to cater for our ECN/ECO workflow. The workflow will differ at every company, which really cannot be provided for by the ECAD tool.

Anyway, I and many others successfully use git for collaboration. Trying to implement git inside KiCad would not be a good idea IMO.

1 Like

Implementing git, certainly not. But why not offering (optional) KiCad interface for some git actions? Like most even semi-advanced programming IDEs do.

KiCad is not an ide and it’s arguable that git is the scm for ecad so why should that specific one be implemented? Centralized one like svn may be better for this use case, even though it has lots of it’s own issues.
A plugin system that would support any type of scm though, that I can see being useful.

3 Likes

Implementation details. The high level view is that I would like to keep save history which could even work as infinite undo history. Ctrl+S would save to a versioning system with automatic message. Having remote repo wouldn’t be necessary for that, but would be necessary for the topic at hand.

But with collaboration comes a bunch of problems, one magnitude more difficult, like possible clashes or locking, or merging which is impossible for most EDA designs, at least with the current KiCad file format implementation and handling. This has been discussed and I agree that git is overkill and doesn’t have perfect features for EDA versioning system.

these guys are trying: https://cadlab.io/

1 Like

Also, although anyone would be forgiven for not knowing, there are versioning systems other than git - some of these have features that might be better suited to EDA projects. For instance, Fossil https://fossil-scm.org/home/doc/trunk/www/index.wiki which has some useful project management tools built in (for instance there is a bugtracker, wiki, tech notes in the timeline, a lightweight forum feature and an inbuilt web interface) all in one single, cross platform lightweight binary.
Also, there are still non-distributed versioning systems - for example, SVN which might be a better choice for library management as you can avoid messy merge conflicts by locking the checkout.

No. Because to me it IS magic. :sunglasses:
I would like a 1 button “collaborate” feature for users who can’t or don’t want to do workarounds or python.

I have requested this feature as a top level requirement, specifically to avoid exposing my lack of knowledge of the details. This approach allows the developers the max freedom.

Soory but i’m on the road and will try the python next week.

I still have no clue what part of the process is missing. As i describe above KiCad is already more than just capable of being used for collaboration. It all hinges on a proper library setup and there you need to make the trade-off regarding control described above.

I kind of get the feeling that you either misunderstand how KiCad and its lib setup work (and therefore do not see how to get to your goal easily). Or you have an inappropriate setup for your usecase and want some automatic way of fixing it.
And you might be held back by not looking into proper version control tools. (Not sure how much any new feature can help here.)


The real issues why KiCad is not that easy to collaborate with is that stores cruft (not design important info) in both the pcb and schematic files (in the words of @Seth_h). And it sometimes reorders lines in the file without good reason (a small change creates a huge difference).

Plus there is no real diff tool for designs. (text based diff works on 1d data while pcb designs are at least 2d -> related to the line ordering issue pointed out above) This means for now one needs to ensure that no two people work on the same file at the same time. (This is where centralized version control systems with locking come in handy.)


Libraries do not really suffer from most of this. Adding assets is something that is easily merge-able (we do it all the time on the official lib).

Changes to an asset (footprint or symbol) are a bit of a different story.

  • In a centralized library workflow you do not allow changes being made without them being discussed so everyone involved knows that a particular asset is already changed by somebody else.
  • In a project local setup the risk of this being an issue is reduced by reducing the number of people accessing the same lib (only the people working on the current project). I would suggest a communication channel between all collaborators. Changes to assets are something that needs to be announced beforehand.

My wishlist for collaboration therefore:

  • get rid of storing anything non design related in the files.
  • ensure adding something does not change too much in the file (consistent line ordering)
  • Integrate a version control API that allows plugins to handle checkout, locking and committing of changes and interacts with open/save operations of KiCad.
    • should also handle submodules of git and maybe offer something similar for svn based setups. -> allow checking out older versions of the files and ensure the library is at the correct state.
  • partial export of a lib table and a way to easily import it at another setup (reduces effort required for the centralized library workflow).
2 Likes

Likely nothing.
I’m on a trip and not able to try the python script right now. Assuming the lib issue is addressed, there is likely nothing else required. My request for a builtin (1 button) function is to make the feature easy for folks not used to running python.

I’m extremely happy with this thread and thanks to everyone that contributed.

You should not need to run python if your libs are setup such that they fit your usecase (Strict or lax setup)

Merge the design not necessarily depends from file format. For team placement (like described above) merge we already had success using itermediate data format import/export (IDF). The format is obsolete for Kicad and was designed to pass info to 3d visualization. IDF is good to learn about how to merge the collaborators contributed work. It is intended for collaboration of electrical and mechanical team and hardly known to use it only internal to merge component placement information into a single design. Here are some infos about file from what we used the emn for part coordinates:

https://www.simplifiedsolutionsinc.com/images/Steps-to-create-3D-PCBs-in-ProE.pdf
http://www.aertia.com/docs/priware/IDF_V30_Spec.pdf

If same can be done with traces (not lib), that would be true concurrent collaboration but always need strong agreement between the contributors.

Here is how others do this for PCB (Dialog Cell-tab = Kicad Footprint, Part = Kicad Symbol) and for schematic. Lib is central approach. After symbols and footprints placed by editor, they have design local copy including simple version info. Existing designs never update from central lib until you have a good reason. 10 years later, no problems with existing design whatever happened with central lib in meantime and even if lib is missing completely. Dialogs for global update also exist but rarely used and dangerous. Dialogs for selective update attached.

My comment was not meant to talk about what happens to designs using assets but about how it is handled if two people make two incompatible changes to lets say the same symbol. Who then decides what change to use. And how can this be efficiently tracked.

There is always a risk where anybody has write access. Compare with Wikipedia - they use mySQL but anything file based like mongoDB would probably better fit the lib. For decisions there is a head of lib…

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.