As I begin to realize how artistic it is to design PCB layouts, using the PCBNew, I am but forced to think "How about a LAYOUT-SNAPSHOT feature?
What I am trying to suggest is this:
As the PCB layout evolves, can I backup the latest edition as a snapshot and retrieve it later when I want to go back and start from there?
Or, I may even be experimenting with more than one layout idea (say for example, all ports of a particular type placed on just one side versus another snapshot in which “all these ports are strewn around the perimeter”?
I am throwing a open a very large idea but I miss the snapshot abilities myself as a beginner. And as I design even a basic amplifier, I am left wondering how the layout looked with a component of another footprint or what was it when I had not rotated the ampllifier around…
Excuse if the feature suggestion seems immature (as is my knowledge of KiCAD) or the feature does not appeal to many!!
depends on your usecase. For git it is totally ok to have temporary commits locally (on a separate branch of course). You can squash them for committing to the servers master branch. If you are the only one working with this particular git instance you can even push the development branch to the server for a securer backup. (You know separate location and all of that.)
Of course they are sacred. For best results also bring sacrificial goat with each commit to please the SVC gods and avoid merge conflicts.
Sorry for the joke just couldn’t resist with your choice of words
Git and other source version control systems are just tools. They are great for versioning text files. Yes, they were developed for source code and are slightly more useful when used for source code but it’s not like git-police will show up at your door and beat you up for using git for something else.
And general philosophy for git is do whatever you want in your local repo. As for “upstream” there may be more rules but even that is entirely up to owners of the repo.
This seems to me to be the same type of thing @maui solved with StepUp. Rather than bloat Kicad when better tools existed he simply found a way to make the two work better together. In his case, Kicad and Freecad.
I’ve set out to learn ‘git’ a few times but get as far as solving my immediate problem and lose focus. My guess here is that the same type of approach might be best. Just do a git plugin?
myproject.sch the schematic
myproject.kicad_pcb the PCB
myproject.pro the project
myproject.net the netlist
myproject.lib components for the schematic
myproject.lib custom schematic parts
myproject.kicad_mod custom footprints
The last two files are OPTIONAL. If you use only standard schematic components and standard footprints, you will only have five files.
When I wanted to experiment with different layout or with different footprints or with different components, I created subdirectories for my “exploratory” layouts, myproject2.pro, myproject3.pro and copied the schematic myproject.sch into myproject2/myproject2.sch, myproject3/myproject3.sch, and so on.
There I changed whatever components or footprints I felt like changing in the schematic myproject2/myproject2.sch schematic file before creating the PCB file.
I created myproject3 in the same fashion to explore unrelated ideas.
This creates extra files, but so what? When you are done exploring, you can either delete the subfolders containing the versions that didn’t live up to your expectations or leave them there to remind you of what didn’t suit you.
KISS
EDIT:
After reading Rene_Poschl’s post earlier today at
I realize that it is essential to add the file myproject-cache.lib to my list of required
files.
Thanks to @Rene_Poschl
So let’s see, that is at least three files and possibly up to eight files are needed
to copy a Kicad project.
I should also thank @paulvdh, as he was the first to name this file. It takes a while for me to figure out what is important and what is not. Thanks, guys, for your feedback and for correcting me.
What exactly do you imagine functionality of such plugin would be?
If you just want easier to use git front end look at any of available GUI apps
And for the purposes of using git with kicad it is very simple to learn, you just need to understand 3 concepts: commit, commit graph, branches. Since there is no meaningful merge operation for kicad data a whole subset of git is more or less irrelevant (rebasing, merge commits, cherry-picking).
Once you learn these 3 add concept of remotes if you need to commit to other repositories and voila - you’ve mastered git for kicad.
Oops.
_Getting_Started_In_KiCad has been the single worst maintained document from all the KiCad documentation. It’s been a thorn in my eye that this document has hardly received any update for quite some time. And not just any regular thorn either, it’s more like Pereskia Grandifolia.
In KiCad V5, projects get severely crippled if the myproject-cache.lib file gets lost or damaged. There are also some screenschots in Getting_Started_With_KiCad, which seem sto date back from KiCad V3, while I do not see a good reason to include the netlist, which can be easily re-reated if needed.
Recently my arse was saved by having a pdf of the schematic after a schematic project got damaged, because of a corrupted “myproject-cache.lib”.
For Eeschema -> Pcbnew it also lists the “old” method of first generating the netlist and then importing in Pcbnew instead of [F8].
The only thing that comes to my mind that would be very useful is a way to graphically diff two schematics and boards. If have seem some custom scripts where someone exported the schematics as image and did a pixel diff what looked like a good first step.
At one point it would be nice to integrate this in eeschema and pcbnew to edit on the fly while looking at the diff and resolve merge conflicts. That would enable a nice collaborative workflow while designing boards. But honestly that’s more in the nice-to-have-maybe-sometimes-in-the-future corner.
A technique for comparing images which has been used for a long time is to continuosly swap between the “new” and “old” (or even multiple) images. This started with pure mechanical methods from at least the early days of stargazig, where moving planets and other things can easily be spotted as moving things on a stationary star background.
Humans, and lot’s of other animals have been genetically trained to be alterted by moving things.
Another very simple, but effective method is to simply only show the differences. Every pixel that is the same between the 2 images will simple get assigned “black” or “white”. (Except maybe for the board outline, because it helps in locating where the differences are on the boards).
I guess just for the number of hidden solutions coming out, this discussion be pinned somewhere on the forum. Dunno if and how, but I leave it for the gurus to take the pinning suggestion or leave it
You can always save current layout under a different filename using a “save as …” in the file menu. And once you are settled on a proper layout delete the remaining layouts and rename the proper one to original name.
Thanks Mitja. I am right now using that saving as a another file method to get around. But the moment we “save as…”, the link between the schematic and the PCB layout is broken. So we do not quite want that.
I simply save the board, and then use a file manager to zip the board file, or the whole project, and also prepend the zipped name with a date in ISO8601 format. This way you always know what your latest backup is.
If I suspect software is buggy I sometimes do this multiple times a day, and then also add the time in ISO8601 format. for example:
2019-04-19T19:52_Project.zip
The numbers stand out in the file manager, and are always easy to sort.
My guess here is that the same type of approach might be best. Just do a git plugin?
