What approach do you take to save revisions without going through GIT ?!

Hi, I came to Kicad5 from years of doing rapid single-sided board prototyping using the self-explanatory expressPCB and although it is a much lower calibre tool one thing it does is provided the simplest way of keeping track of design revisions - merely by saving and re-naming .pcb files

I tried figuring out how to do the same (ie., manually) in Kicad5 but I ran into issues with the fact that Kicad re-dates files once they’ve been opened which screws up the time-stamp that I sometimes rely on for finding pieces I’m working on …

I’ve tried saving multiples pcb-new files within projects but something was telling me maybe this wasn’t the right way to do it. Alternatively I’ve been experimenting recently in Kicad6 with using the save-as command from within the .pro window but that seems to be generating nested backups of backups - making me suspect this is not the way either.

I’d like to know how to get a better handle on this aspect of Kicad - especially from those who don’t go through GIT
// thx!

My take is that git is not as scary as people think. I use about half a dozen git commands 97% of the time.

edit, edit, edit
git diff
edit some more
happy
git add .
git commit -m ‘Fix the multiplexer’

That’s it!

As a bonus publishing to GitHub is just

git push origin main

1 Like

Or self-hosting via Gitea - lightweight and simple git forge. It also includes kicad .gitignore

it really isn’t that scary and if you use windows the likes of tortoisegit provides visual overlay (and simple command interactions) - thunar and a few linux file managers have comparable capabilities.

I wonder if there is any merit in raising a feature for basic git integration… Matlab provide UI integration and they have vastly simplified interaction with git and thus removed it as a barrier (to encourage it’s usage to protect you from … you)

1 Like

I save revisions without going through GIT

  1. The project folder and all KiCad files in it have the same name.

  2. This name includes a date and/or revision designator.

  3. When I want to make a new revision, I copy and rename the (copy) folder and contents. This takes a minute or two using Windows Explorer. I can zip the older folders if I decide to do so.

  4. I have been doing this for some years. Works well for me.

Put another way, doing version control in this way is a method which is almost identical to what I do with everything else, such as spreadsheets and word processor files. I am going through many revisions of test data and BOMs for my power converter, and this method for KiCad files is similar. The only real difference is that for KiCad it is a whole folder instead of just one file.

I can see that my method might result in bedlam if several people were all working on one design simultaneously. But so long as only one person has custody of the file at a time (or ever) I do not see any problem with copying and renaming the entire folder and contents?

1 Like

You can also use the “archive” feature of the project, it will automatically zip your project folder and subfolders, leaving the backups out of it.

it really isn’t that scary and if you use windows the likes of tortoisegit provides visual overlay (and simple command interactions)

A side note: I highly recommend this http://gitextensions.github.io/ FOSS GUI overlay for git’ing on windows OS. I mostly never use command line when discovered this tool.

That’s how I do it since years as well.

I second this approach, very similar to what I am using: I keep this folder structure:

In case I want to reorder PCB of version “v0.9” I get all the gerbers and ordering information inside \Releases\v0.9 subfolder.

When I want to troubleshoot “v0.9” board, I find exact schematics, part numbers populated at Batches\date-v0.9 folder.

When I accidentally see possible way of improvement of last release, I go to \KiCad folder and modify project on the fly, append “Version history” text section in the schematics. When I accumulate enough improvements for PCB release v1.1 PCB release, I archive sources to \Release subfolder, and true assembly information in \Batches subfolder.

3 Likes

Why do you keep your assembly information away from your releases?

“Releases” subfolders are only for PCBs (orders from pcb factory) like pcb “v1.0”, because this data is stationary. One board revision has single 3D model, solder paste stencil, set of gerbers, one set of mechanical drawings. I can run multiple assembly batches on this single revision pcb. Each assembly batch may differ in subtle part numbers (for instance, resistor tolerances). Each assembly batch has slightly different bom which may be reflected in separate schematic drawing (if I was not too lazy to reflect bom changes into eeschema and reexport schematic pdf with updated batch string). There may be plenty of these assembly runs, and I thought to keep pcb revisions (stationary) and assembly batches (dynamic) in separate folders to reduce clutter.

I use https://partsbox.com/ to generate pdf boms (hand soldering). For each assembly batch I spend couple of hours to run through partsbox bom (imported from KiCad directly via https://github.com/WhiteChairFromIkea/KiCad_PartsBox_BOM). Boms usually differs because of what I have in stock at that particular moment. This is a back and forward game - change comment in partsbox, do the same bom change in eeshema. Lately, I also began to use https://github.com/openscopeproject/InteractiveHtmlBom, and this is a third part in this back - forward game, i need to synchronize eeschema, iBom and partsbox database. This is a tedious job for first assembly run, but not much to do for later runs, when only several components changes. But I have plenty of information about what is soldered in particular board later (for troubleshooting). I mark boards with stickers to keep track of assemblies.

Best way without using git: Use Mercurial, GNU Bazaar or SVN.

I highly recommend you learn how a VCS works. It does not matter that much which you prefer. I personally would use something that can be used local only, without ever using a server, like Mercurial or git.

Agree with @retiredfeline here. I was a very reluctant git user and found it all rather arcane but for use with KiCad, you need to understand very few commands. A graphical interface like Tortoise Git on Windows or Snail Git on macOS makes things easier.

It took me a couple of days to get the hang of the concepts but it is worth it. You just need to add your project frites to git with a git init and a git add . Once done, it’s all now managed under version control.

You get a meaningful point to which you can restore to - provided you write a meaningful commit message. Most helpfully, it means you can try out things without worrying about your work. Say you want to try a different regulator position you can git branch regulator-pos and then a git checkout regulator-pos (Or equivalent in gui) and you can hack away on your design. If you like the new version, you can keep it git commit, if you don’t then just switch back to your original with a git checkout master (You need to commit or stash your branch first as git tries to protect you from deleting stuff accidentally. So four commands init, add, branch and checkout

Personally, I now use Fossil - opensource, distributed vcs as it’s better for my style of working and has lots of extras - bugtracking, gui, wiki etc Fossil: Home and works very well with KiCad.

2 Likes

That makes a lot of sense, thanks a lot for the explanation, I do not deal with many variant of the same board, as such was difficult to grasp the concept correctly.

I think git is a wonderful program but I’ve never managed to get my head around it and to learn it properly.

For my own stuff (mostly microcontroller firmware and KiCad projects) I’m quite happy with working with zipped archives.

Each project has a text file with notes, and part of those notes is a revision list.
Whenever I feel like archiving a project at a certain state I do:

  1. Create a line of text in the notes text file. The line starts with Save: 2022-02-18 Kicadean example The "Save: " starts on a newline, so I can easily do a grep on this througout the notes to get an overview.
  2. Exit the project, cleanup temporary files and backups KiCad makes itself.
  3. Zip the whole directory, and give the zip file a date in ISO 8601 - Wikipedia format.
  4. Open the zip file and look if it has some obvious big data it does not need to have, such as 3D models.
  5. Spread the files around on some external devices.

It’s not as powerful as git, but it’s adequate for my purposes, and it’s extremely simple.

I have made a few attempts to get more into git for contributing more to open source projects, such as the KiCad documentation, but there is always some thing in git I get stuck on and can’t get past.

1 Like

I really do not know whether that is a typo or some (new to me) jargon term.

Pretty much all of the GIT explanations I have encountered use jargon terms which lose me by the first or second sentence. But when I see “command line” I think “forget it. That sounds like programming.”

Project frites

Don’t you use chips in your projects then? Haha typo!

One of the GUI wrappers to git like Tortoise or Snail Git or whatever suits your OS takes away any pain of using the command line.

As in pomme frites? I do not speak Russian. (I am kidding. I have been to Paris a couple of times. But I bet that many Americans would be unfamiliar with frites - chips - French fries. But:

What did you intend to type without the typo? I still do not know…

I see it as two choices:

  1. Find some new software to interface with a mysterious website to store and organize my versions.

  2. Copy and rename.

(2) sounds much easier.

This discussion does lead me to think that a revision log (in the folder one level up) might be helpful. Rather than some sort of text file in each folder which is what I had been thinking. I have never done either…

1 Like

I believe the intended wording was project files.

A mysterious website is not a must. Git runs local, once installed can be used without internet connection.

Any mysterious website able to host you repository is one of the benefits of using a VCS IMHO.

Project files (not Project frites) :stuck_out_tongue_winking_eye: Really don’t know what autocorrect was thinking. Now just recovering from a power cut from Storm Eunice in UK (122mph winds 10 miles down the road)

This works best for my project management… Been doing it this way a long time and, though the software I use changes every few years, my approach stays the same…

For my Kicad Projects, I do this:

• Create the project, such as MyProject_V1_R0
• I copy the PCB and Schematic files and Paste them back into the projects folder.
• I rename them if needed
• For a New or modified PCB/Schematic, I either create New one’s (using the Icon’s) or, Copy and Paste previous ones and change the names

Result is a Project with multiple PCB’s, Schematic’s, Netlist’s…etc

Each File’s Sheet has the correct FileName in the Legend

For Project Management (tracking) I use a DataBase I created in Libre Office (here’s a link).
I call the DataBase by a Plugin

Vid below shows example…

Example of File Tree in Kicad

Proj_Tracking

1 Like