The added changelog is indeed quite important when using zip files.
Instead of “version numbers” I also use date strings in ISO8601 format on both the schematic and the PCB, and these correlate to the dates used for the backups.
kdiff is a good argument for using GIT.
Zip files are attractive for their simplicity, and you can directly use KiCad project manager / File / Archive Project to make a backup. I do have some mixed feelings about this function though, as it is unclear to me which files it backs up. I’ve had some extra info added to a project directory which did not get archived.
If backing up a projectx, I would include a projectx.README.txt text file in the projectx directory. That would be my “change log”, whereby I would force my future self to remember the reason I saved this particular version of projectx.
Thank you for the reference to Fossil. I will take a look at it and see if I can tell whether or not it is useful.
Unfortunately kdiff is the name of another application which compares files, i.e. shows differences between them. This should be rather KiDiff or something like that to avoid problems.
Anyway, a diff program is a file difference finder and visualizer. It’s very important in version control systems because seeing the differences between commits is one the core features. In git and others it’s usually a text based tool which shows differences between two versions of a text file.
In programs where the edited thing is graphics, text based comparison is often meaningless. This kdiff does graphical comparison by letting the user compare two images visually.
I like this idea, mainly because I already use the month/day/year (YYYYMMDD) part of the date string to prefix filenames in order to explicitly remind my future self when I created certain text files.
I create a number of folders and just move from one to the next copying all the files. As mentioned above I keep a txt file in the project to keep track of what I’ve done.
This works for me because as a hobby I can afford the time to tweak the design. Say I have all connected then I want to rotate an IC.
KiDiff was my original pcb layout diff program that works with Git, Fossil and SVN repos. (https://github.com/Gasman2014/KiCad-Diff). More recently, @leoheck and I collaborated on ‘kdiff’, a combined schematic and layout diff program which @paulvdh linked to earlier. I agree, in retrospect, ‘kdiff’ might not have been the best choice of name.
Hey guys, I did not read the whole conversation. This may not be the toppic of the thread tho.
kdiff was just an experiment that worked really well actually. I think you can rename my kdiff script to something else. It won’t give you any problem.
I think, most of the “k*” tools were make for KDE window manager for Linux, as the “g*” ones were made for Gnome. But this is not the the rule, I think. It is more like developers humor than anything. So the original kdiff may fit this, and since I dont use KDE and its tools, this didn’t interfere with my tool on my system.
With that being said, since John and I was colaborating to make this new experiment/tool. And then then just started from his “KiDiff” name to something similar but shorter and lowercase since I am a fan of easy to use command line tools. Then I saw “kdiff” was a good choice, since the command line arguments for both tools were the same at that time. I just had to remove an “i” to toggle tools (since I was testing it a lot buy myself)
But of course, I am open to suggestions to name it since it is a working tool and since I am seeing many starting to use it too. And also because it works multi platforms.
Nowadays there exists kdiff3. Doing a google search reveals that kdiff is either a name of an older app, older version of the recent one, or just used as a shortcut without the number. Confusing anyway. (BTW, ‘3’ there probably refers to 3-way diff or merge, not to a version number.)
Oh, now I could read the whole thread. The original question has nothing to do with the last messages including mine. Sorry for hijacking the conversation.
The “save as” is the way you can do this as you already know. However Kicad requires the PCB file (.kicad_pcb) having the same name as the project (.pro). Why? Because it stores extra information required for the layout in this file too.
I think you have 2 options here:
Since the new .pro file is re-created by default when you open the new layout, you can copy and name your main schematic page to have the same name to the layout too. This way both (schematics and layout) will be still related. You could also symlink it to the original schematic, so you could have 2 different versions of the board for the same schematics - which is awesome - by the way.
What I used to do in the past was to save these temporary layouts inside the project, and when I wanted to compare them visually I would duplicate the whol project folder and then in the copy, I removed the original.kicad_pcb and also rename the original_v01.kicad_pcb back to original.kicad_pcb. And you can also delete any possible original_v01.pro existent.
These things are pretty simple to understand and do. But if you use git, you will have better tools to manage versions/control/observe different versions of the project.
To conclude, Kicad does not have this functionality where you can have 2 or more board versions of the same schematic easily. This might be due to the fact that footprint information is kept inside the schematics files, and most of the time, when you want a second version of the board, you would probabbly change footprints too (and also the schematics to be honest).
I personally use version control to save intermediate steps, but wanted to mention that in the nightly build (and upcoming 6.0) there is an automatic backup function:
You can adjust these settings to determine how often backups will occur, and how many old backups are kept. The backups are put in a zip archive and named according to the date+time.
This is NOT a substitute for a proper disaster recovery backup setup (for example if your computer dies, or is attacked by a virus, etc). But, it can be a convenient way of having access to some previous states of your design.
@craftyjon
Looks good to me. One question: Can I trigger a backup manually in 6.0, instead of clocked triggers? I’d like to decide when to trigger a backup, e.g. before a bigger change or after a subsection is finished.
This opens a file browser window and lets you choose a filename and location.
It also does not blindly backup everything. For example it does archive the backup directory in the project.
I’ve always been a bit wary of this fuction. I regularly add some extra files with nodes, maybe even a directory with some datasheets or documentation to a KiCad project, and I never can remember what this archive function does, or does not archive.
It’s best to use an external tool if you want to backup all kinds of files or a directory structure in addition to your KiCad project files. The archive tool (and the automatic backup tool) will backup some, but not all non-KiCad file types.
