Newbie here, just started attempting to use KiCad. I’m coming from an Altium/OrCAD/Eagle background.
I ran across this rather exciting article https://jnavila.github.io/plotkicadsch/ and realized it is the beginnings of Revision control similar to what Altium uses, except this uses Git! I’d love to see this in KiCad.
Comparing versions in Altium produces a schematic which “no change” shows the schematic in muted colors, change show up in normal high contrast color. Being a “new user” I can’t post a second image, so if interested I can also provide this image to anyone who is interested.
The files in Kicad are all ‘text based’ which makes them very suitable for management in version control. You can use whatever system floats your boat - Altium use SVN, I believe, but you can use Git, Darcs, Fossil, CVS or whatever to manage your KiCad project (and libraries). The difficulty lies in interpreting the diff. Altium have developed a tree view and a method of visualising this in a native interface/canvas.
There are at least two schematic diff projects that I am aware of. The plotkicadsch project you mentioned developed by @jnavila and the eeshow project https://neo900.org/stuff/eeshow/ here. This was developed from some earlier work here http://projects.qi-hardware.com/index.php/p/eda-tools/source/tree/master/schhist.
Whilst all of these are quite promising there are some limitations - e.g. Eeshow only runs on Linux, plotkicadsch / plotgitsch (unsurprisingly) only works with git archives. Currently the native schematic plotting routines are not scriptable so these programs have had to develop their own non-native rendering processes. Whilst the KiCad format is version control “friendly” it could be more so and this does not mean that there is an easy route to making sense of diffs and merges. There was a recent thread on the forum about this which raised some important points.
If course, as well as diffs of schematics, the same issues apply to diffs of pcbnew files - hopefully some of the new scripting work that @pointhi has been working on Net-aware pcb diff tool (kicad-python demo)
will make this more achievable without having to resort to plotting output files and performing image comparison tricks.
Thank you for links. I’ll be doing more reading, and probably writing.
I run both Git and Subversion on my server. I’m trying to use Git for new development activity, but still find SVN easier to use. The reason I prefer Git for “new” development is the “server” model Git provides is more flexible. With Git, the repository is local, making it well suited for times when there isn’t Internet access; airplane travel, bad/expensive internet, or even military (blackout) secure areas. Yes, SVN can be used “locally”, but then you have to make a choice, is the SVN repository -only- going to exist on your laptop, or is it -only- going to exist on a remote server? With Git, you can do both and use push/pull/merge operations to keep the two in sync. Then if your laptop is stolen at the airport, run over by a truck, falls off a cliff/bridge, burnt up in a fire, lost in a tornado or flood, you can easily recover with new hardware, reinstall Git software, then a simple Git Pull to restore a complete copy of your design repository from another laptop, or a server. From a failsafe point of view Git stays up to date in 2 or more locations with “normal” operation. SVN doesn’t. I’ve also encountered WAN performance issues using SVN as part of a Issue tracking backend with the server in Texas and remote site in Washington. What took 2 minutes to process locally took over an hour due to WAN/SVN transaction latency. So in my mind, Git is the only real path forward, but I still love the ease of usability and familiarity of SVN. Tortoise revision control shells help a lot, but then there are those times when you need to get closer to the bare metal of your repository system to fix issues.
And BTW, I spent years as a Hardware Development Lead and can tell you hardware engineering is definitely a collaborative process, sometimes contentiously so. Git/SVN at least assist to get the hardware design on the same page while two usually very smart and opinionated guys attempt to work out their differences, too often with a lead stuck in the middle. I’m talking larger designs, 4000 nets+, often multi-board mixed signal analog/digital, while trying to keep the whole design synchronous and noise minimized. Yup, good times, but I enjoy working with people.
If you are evaluating versioning systems, you might like to give Fossil a check out too (www.fossil-scm.org)
It is a distributed versioning system like Git - so has the advantages of that workflow. It is a single, small binary which will run on any platform. It also has bug tracking and a wiki built in - so you don’t have the issues you allude too about separate issue tracking (and now it also has a forum feature with email too). It is simple to set up and highly network efficient. It is under active development by the team behind SQLite. It has a similar workflow to Git but seems to be somewhat easier to use & I have found it well suited to EDA projects.
(Off topic)
You can stay with SVN, and use git svn to checkout only folder in SVN that you like to work on. Then you can enjoy off-line commits work and do dcommit afterward (when SVN server is accessible).
I had developed a script do bidirectional sync. between full history of any chosen folders from SVN server and git server. It automatically run on schedule, or hooks. People on my team free to work on SVN, or Git, or both. I love to release this scripts, but still have to do ask for permission!
TortosieGit, and TortosieSVN have customize diff which allow you to diff-binary things (word, excel, VI labview .etc…). If we have kidcad-diff.exe, then is would the wonderful.
The thing is most diff tools perform file to file diffing, while for eeschema, the diffing must take several files into account (schematics and libraries). So this is not the correct granularity. Please note that this is also the case for merging.
Agree. However, event at file level it already a great help at least for me. For the full compare level, I think user need to manual checkout the 2 versions, and do compare (but with the same kind of tool like kicad-diff ).
@Jean-Noel_Avila Ideally you are correct, and achieving this objective is an excellent long term goal.
I’ll echo @nhatkhai’s point that following the 80/20 rule, great value can be realized initially if only eeschema has Git diff capability, for now.
Lets look at a couple Usecases where “Assume” the eeschema part U1 doesn’t change when in fact in the Library it does:
Let’s say the only changes in the Library were to move part interface pins, same part, same pins. This would be reflected in eeshema with wire and/or surrounding component movement.
Let’s say no interface pins changed, part function is the same or similar. Would an eeschema catch this if all that changed is Vendor or Part number? (second vendor source example)
Let’s say a pin function changed. i.e. the pin may have multiple functions like JTAG interface pins have more design value if JTAG capability is dropped and pins are reallocated/configured to be used as GPIO. Maybe the library part pin name changed, or maybe it didn’t (JTAG CLK -> GPIO34 -> JTAG CLK/GPIO34). Maybe surrounding parts were modified, or maybe they weren’t (existing signals routed to two different connectors). Would or should this Library change show in a eeschema diff?
Let’s say the library part radically changed, pins moved, labels changed, like after a “new part” library review with a room full of engineers. From an eeschema “diff” point of view, “U1” is the same part, but all the attached wires and components moved. (Someone wanted inputs on one side, outputs on the other, or wanted clock/power pins grouped, or …) It would be useful to see the movement of surrounding wires and parts. This would be a big clue that something may have changed in the library, and re-validation or re-verification is now required on what might be a 500 pin BGA library part.
What about a change in the Library where schematic and pcb footprints are the same, but a SPICE model, vendor information, IBIS model, manufacturing incircuit test models were changed? in eeschema (and PCB layout) this change is irrelevant and I wouldn’t want to see this diff change.
My point is including Library diffs at this time could be a very large feature killing issue in the initial eeschema diff representation. Let’s start with just eeschema version control for KiCad v5 or v6. 80/20 rule says we’ll have many Usecases covered and learn a lot more about complex eeshema/library/PCB interaction Usecases with a functional eeschema VCS diff capability. Save PCB Layout diff and Library diff for future tasks, and start issue tracking for the these future VCS diff efforts now, so ideas aren’t lost. Integration is usually last, but needs to be thought about/considered up front.
With these Usecases, from an eeschema “only” VCS diff focus, how should these Usecases be represented? Can they be represented? Maybe they should be recorded in an issue tracking system and ignored for now.
My point is just that common diff utilities provided with VCS are usually per-file. The diffing of schematics with libraries included is already done by eeshow and plotgitsch. I can tell you it is not a big deal, provided the underlying VCS does correctly the tracking of changesets across multiple files in a directory. eeshow allows to navigate in the history, to show differences for not visible properties and more.
As for integration, I guess that would require an advanced plugin system in eeschema which would open a lot of possibities of extensions such as custom part management or exports to other formats or integration with third party tools.
).