My private solution would be to first make the full project with elements from the source that they are generally bigger. Then I’d copy project under different name and replace these elements. Changing from bigger to smaller should be easier then the other way around.
As was said, it really depends on whether you have only one footprint for each part and two possible sources, or two components which require different footprints.
In the simple case the most simple solution is to just have two different fields, for example PartNumberC and PartNumberU. I don’t see anything special here. Just select one of those two fields for the BOM.
You can even give the same Label for both in the BOM generator so that the field name is always the same and doesn’t depend on the symbol Field name:
I haven’t used database libraries, but I think this system, too, can be combined with a database and two different “house part numbers”.
Hello,
I like your ideas. I am trying to visualize how this would work on the actual schematic part. I think that there are alot of ideas in relation to the BOM and I like their appraoch.
One thing to note is that for some of the components, these are ICs. Their functions may be similar but their pin outs (and packages, and footprints) are all very different from each there (ok, maybe not that different. One is a QFN 24 and another QFN 64 for example). And then the next question is how this would look like for the BOM
So I am wondering if I should have 2 sheets of the “same” circuit. One for US and the other for Chinese.
I’m getting the feeling that the layout is going to be sufficiently different that you are going to end up making 2 projects in the end . . . maybe make one then use it as a basis for the second. Pity, as if you then need to make any mods you will need to do it twice.
1 Like
I would not make this kind of change in the BOM. I would make two entirely different projects.
Sometimes it’s too much work to turn a terrier into a parrot. Search for “Monty Python pet conversion” to understand. 
Another option is to use KiBot and its variants feature. I’ve used it in the past and it was very easy, because I used KiBot in my setup already.
The only issue is, that the variants works great for schematic, but do not work in PCB. So you basically need to have both footprints in the PCB and it will manage to set the correct flags in BOM, position files, etc…
Hello all,
Thanks for the feedback. @Kedarius I haven’t used Kibot yet but I did look into it some time ago and I do feel that it is a very useful thing for me to start using. I will take a second look at it. Maybe this will get me started using the tool
I also was thinking that since I have this under source control, I can just develop it out using Chinese components (also noting the US subs). Once I have the schematic where I want, I can create a branch off of the Chinese one that is for US components. That way I can kinda have 2 different schematics/layouts under 1 project.
Unfortunately, the biggest drawback of using KiCad with version control is the merging. While I advocate for using git with KiCad, and it makes it easier with the automation, etc… the biggest issue is that the KiCad files are not made for text editing (obviously). The format got better over the years, but still merging two branches is tedious work… So expect that if you split it into two branches, you will never merge them again, and you will need to do all changes in both of them…
I still think that it is the best option, but I just wanted to give you an advance warning 
This is only a drawback if you try to merge things. While this point is a common thing raised, in my experience it is perfectly possible to use version control while never merging anything, which works quite well with KiCad (and any other software where merging is non-trivial)
This limitation with merging is inherent to any format which tries to represent 2D or 3D data. Text or binary, the file is always one dimensional. It’s not about optimizing the file format. I mention this in Pros and cons of using a VCS (git etc.) with KiCad and it’s explained with examples in Tools for cooperation?.
That’s exactly what I wanted to say, I hope it did not sound any different…
I strongly advocate to use Git with KiCad and I am using it for all my projects, however the inability to merge things is a big obstacle in a multiuser environment. While with for example software development you can have multiple people working on the same project at the same time and “all” you need to do is to merge their work afterward, the Git+KiCad workflow is limited to one engineer or very small team, that can manage to avoid conflicts without the help of the versioning system…
I disagree here. Git+KiCad workflow is fine for a large team. The only scenario it doesn’t work well for is the scenario where you want to have more than one person working on the same thing at the same time, which in my experience actually just doesn’t come up that much.
At work we keep all our CAD designs in a single Git repository and have many people working out of it. It is far more common to have many people working on many different projects, than several people trying to work on the same PCB layout at the same time or something like that. In fact we almost never try to do the latter, and it’s fine.
I know and I partially agree. While it would be a nice theoretical debate, how many dimensions does the file have, the most important part is how good are the tools for merging.
For example, if KiCad would have a nice UI for merging two/three versions together, it would be very easy to merge KiCad projects, and it would not be important whether they are 2D,3D or nD…
And that is exactly what I referred as
You have rules/colaboration techniques (“Hey John, you still working on that PCB?”) to avoid the conflicts by not working on the same files…
I just think your language is not precise and could give people the wrong idea. You say Git+KiCad is not suitable for larger teams, which is not really the case. There seems to be an assumption that the larger the team, the more likely it is that two people will want to touch the same board (or whatever) at the same time, and I don’t think this is true.
I think a more correct statement would be “KiCad does not have any tools that make it easy to share a single file between multiple people at once”, and this is true no matter whether you use Git or anything else.
However, if you don’t want to try to share a single file between multiple people at once, you won’t have problems. And “using Git” is really not the same thing as “trying to share a single file between multiple people at once”. It is quite possible to have a large team of people using Git as long as they don’t have the idea that sharing a file is possible/easy.
Another point is that even if KiCad had a graphical diff tool, you would need out-of-band communication in my opinion to attempt something like having two people work on a single PCB layout, so that they don’t undo each other’s work or otherwise waste time. I suspect this is the main reason that the big commercial tools that support collaborative PCB design do it with a real-time client-server approach, rather than by using version control and merging.
1 Like
Well, I really hope that if a large team wants to use any kind of tool, they will test and evaluate it without too much taking into account any “internet advices”
Because for example it could still be useful for the team to even work on the same files if they would come up with a way how to merge the work (i.e. hiring low level engineer to do the merges manually).
I do disagree with this statement. This is exactly how it was with a software development in around 2000. It was a crazy idea that two people would work on the same source code at the same time… And now we have git, three-way megres, documentation, tests, atomic commits… For me this is one of the most important improvements in software development…
And the same could be implemented in PCB design… For example, having a board with MCU and PSU, why you could not have one person working on PSU and second on MCU? Of course you would need some coordination, but that could be inband - i.e. everybody working on a different schematic sheet while providing common API (global nets and hierarchical pins) with documentation (inband like in software source code) and with everyone having assigned their place on the PCB, where they can do their work? Yeah, it may seem crazy and not implementable and definetly not present in current tools, but it could be done, it is just a lot of work… Probably same amount of work like going from simple TurboPascal IDE with integrated compiler to complex IDE with build servers and version control…
But I am afraid we kinda stole this thread for an slightly off-topic discussion
Interesting remarks.
If I can chime in here. I think that you can use whatever tool you want in order to get the job done and also what meets your requirements. For me, myself and another engineer use Git with KiCAD because we are also software developers and we are familiar with the system. yes, merging is a problem especially when it comes to conflicts. But we have figured a way around it by making sure 1 person is editing the files at a time.
If Git works for you, go for it. If SVN works and you think that it is best, go for it.
The most important thing is that there is version control which I think we can all agree is needed even on hardware based projects.
Also, I plan on making another branch for US parts. I don’t plan on merging this into the main branch it is pretty much be it’s own thing
I completely agree, use whatever tools work for you. I am also primarily a software developer, and so I use git for all my projects: software, electronics, anything…
But as I am the only one working on KiCad design - all my colleagues help with the design ideas, datasheets, finding parts, etc… but I am the only one who puts it into the CAD form - it is easy for me to make sure that I do avoid conflicts. I am also using submodules for my libraries, so the git repo could get quite messy very quickly.
However, once I forgot to push work from my notebook and noticed it after I did some work on my desktop… It was easier to redo the work than try to merge the commits
And for the on-topic discussion, I feel like we in Europe will need 3 branches soon