"Forking" a project (V7)

Since (and because) the project structure has change after V5 (and I skipped 6 entirely), I thought it best to get the definitive answer to the question: How best to “fork” a project, so that the original is safely stored while I explore some major changes to the schematic and PCB in a derived project?

Please excuse me if this is too dumb an answer. But at least in V7 if you save the entire project folder that should contain the needed symbols and footprints so you would have all that you need, other than the software which I think you can still download if needed. For safe keeping, I would put a copy of the entire project folder into a zip file.

I do not know what was the earliest version which contained all of the needed information in the project folder but I think that at least version 6 did that.

BTW I like your avatar. Is it a Van de Graaff generator? The world needs more Van de Graafs. :slight_smile:

Just make a copy of the v5 project in another directory (including any -cache-libs) and convert that to v7. You may find you will also need to bring in some library items from old v5 libraries. Whether you store them in a project library or migrate them to a personal v7 library is up to you.

Later you can clean up the detritus, like old .pro .sch -cache-lib files that are no longer needed.

Obviously keep an untouched copy of the v5 project so you can fallback to this checkpoint. But done right you should never need to use it again.

Indeed, just make a backup before you start the conversion. Your V5 project may also have [Project]-rescue.lib files that are an inherent part of your project and you should backup that file too.

It is, in fact, a Whimhurst machine.
Yes, I think you are entirely correct about the fact that since v6 an “archive” contains all the data required – no need to create or migrate separate cache files for footprints / symbols / 3d-imagery.
My inquiry, though, was aimed at discovering whether I can simply re-name the visible files, or whether there are ‘hidden’ for which the linkages will be broken.

1 Like

Why would you want to take the risky shortcut of renaming the files when the conversion takes little time.

There seems to be some confusion: I mentioned v5 only because I am / was familiar with the file structure there, before migrating myself directly to v7 (ha ha, only to find that now it has been surpassed by v8). The question concerns creating a copy of an existing v7 project, which I would then re-name and use as a “fork” with some significant changes. If the fork goes down a blind alley then I can always return to my original Project.
As I mentioned in reply to BobZ, I was wondering whether there would be internal linkages (to hidden files, etc) within the copied Project, that would get broken in the process of re-naming that copied project.
Also, What is the best way to create a copy of the project? In v5, I just copied the contents of the entire project folder into a new folder, under a new project name, and renamed all the files accordingly. Is creating a ZIP archive the preferred route? And, do you rename the contents after un-zipping, OR, do you rename the ZIP archive, first?

I don’t bother to change the basename of the project files. The directory name does not need to agree with the project filenames. Thus I have project directories like blink, son-of-blink, this-time-for-sure-blink, and so on, but the files inside it are all blink.kicad_pro and so on. :crazy_face:

The easiest way is to just zip up the old project and archive it somewhere. Chances are you will never need it again. I also don’t know why you would want to go renaming project files. More different project names just make it more difficult to keep track of your projects. I do make a log file for a project with important notes. And in those notes I usually make some remarks of what and when I did (such as backup V5 version before conversion to V8). And I zip up that file into the archive. The archives themselves get prepended with a date in ISO_8601 format. That way I always have a chronological order in my backups.

Some people put the thing in Git, and that is a valid strategy too. Using Git properly does need a bit of studying though. Git repositories also tend to get quite big, and frankly, I do not see much use of keeping the whole history of a project in the way that Git does. Managing a few zipped up versions of a project is “good enough” for my own purposes.

I used git branch for the alternative “experimental” version when I wanted to check if I can convert one 4 layer board to 2-layer version easily. Once that worked, I merged the changes back to git’s master branch.

I just use the Save As option in the Project Manager File menu. This option creates a directory of the new project name and renames the project files for you. This option is available in KiCad 6 and newer.