Hey @all
i usually have some itterations of the same Project like v00, v01 and so on. I like them to be all visible in the three view in the main KiCAD window to quickly access them if needed. To do that i create a xxx.pro and create subfolders with the names “v00”, “v01” and so on where the respective shematic and board files are placed. In the end it looks like this:
I was just wondering how anyone else does this (if at all). Which way do you prefer?
1 Like
KiCad does not really support having multiple projects in the project viewer at the same time. You will get strange results that way.
So far it has worked for me, but granted the structure is not very deep and i haven’t done it alot yet.
What do you mean by “strange Results” ? What exactly can/will i break that way?
Project local libraries will not work (both projects will need to share them). KIPRJMOD will not point to where it is supposed to point to. (breaking portability)
Symbol caching and rescue will be broken. (meaning you can not change anything in the library without breaking your project. At least not as reliably as it should work. And with these low expectations it can only get worse.)
Clicking the start eeschema or pcb_new buttons will not work.
Here the things i am not so sure about:
update pcb from schematic might not work. (if eeschema was not open when you started this tool. Not sure if it will even work if eeschema is open.)
cross highlighting of nets might not work. (here i am not sure. would need testing. I am however certain that you will not have a guarantee that it works.)
And i am sure i forgot a lot of stuff.
In general a major assumption of kicad is broken so anything can happen including loss of data. (And devs are fully in the right to reject any bug report resulting from such a missuse.)
A better solution would be to have both projects open in their own kicad window.
1 Like
I just use git and tag commits that I think I may need to get back to in the future.
@Rene_Poschl strangely enough nothing of the above has struck me yet. I have to admit thou that i neither use local libs nor know what KIPRJMOD is supposed to do/provide.
Symbole Caching and rescue seems to works so far but again i only use global libs. The netlist export and read in does work, i haven’t noticed an error there either. The net highlighting does work also at least so far.
Still it might be not a good idea to do it if it is not intended.
@qu1ck
I also use a svn to archive anything but for example iso 9001 request seemles documentation which means i find myself switching over the iterations to add information to the previous version of the schematics whilst already a new one was created…i feel like it would be a pain to constantly reverting and updating between revisions.
Change a symbol in the library and rescue it in the old version but not in the new one. (after all you do not want to change a past version only the current one if you ever are in the spot of needing to change an existing symbol.)
My guess: you will need to choose between rescuing it for all versions or for none of them.
Broken indeed 
glad it’s like the first project i’ve done it this way…
I use version control software (Git, SVN Fossil etc) to keep track of project progress. Bit of an initial learning curve but worthwhile. Git is complex but you really only need the basics. I would put a special word in for Fossil (www.fossil-scm.org) which is lightweight, self contained, easy to use and well supported. I used to keep dated revisions or Rev1 but this is unhelpful as you can never quite recall what you changed between 1 and 1.1 - however using any SCM makes this very easy.
People often think that Git et al involves a lot of arcane command line incantations - whilst this is true to get the full power out of it, in point of fact the linear workflow of most EDA design (with occasion branches but rarely any merges) is pretty straightforward to manage in any SCM. If you want a team to collaborate and merge stuff together this is more difficult. Just as an example, using Fossil, you can use the in-built web view to inspect the history of the repository very simply and see where stuff has changed. It is then very simple to jump between revisions and branches, preserving all the history as you go.
2 Likes
Fossil does look really nice. I will have a closer look at it, thanks for your input 
Learning Git is still on my todo / wishlist.
Untill then I get by with simply putting the whole project into a .zip (or .tar.gz) file.
I keep the compressed archives separated by pre-pending them with a date in ISO8601 format, which keeps them ordered in chronological order.
https://en.wikipedia.org/wiki/ISO_8601
Usually dump the archives in a separate physical medium. (USB stick, or external HDD).
Still have not gotten around to properly configure some kind of NAS lookalike for proper backups.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.