@bobc: so you agree that the lack of version controllability as a feature might be partially due to (well founded) conservatism, it’s just not in the EDA software side only?
As you say, a big company is unlikely to take the risk of trying collaborative PCB design or versioning a single PCB with branch merges, since mistakes can cost a lot. In this sense, I think KiCad could be perfect platform to try it out and see how useful it would be in the real life, as it’s anyway used largely by hobbyists and other people who can afford a bit more risk (remember that even CERN still officially supports only Altium). Also, this is not a feature that should cause anyone to shy away from it, since you’re not forced to use version control, or if you do, you’re not forced to merge changes between branches if you’re afraid of the risk.
@Martin_Layley: so you think that the collaboration side of this could actually be useful in large commercial projects?
Like any other project, you still need a design lead who mantains overall responsibility. The ability to assign sections of work to other people can speed up certain design/layout tasks.
The alternative is for the team to hand draw on paper and then pass over to the single CAD engineer. Worked like that at Samsung 12 years ago.
I think the idea has merit, and there is certainly some chicken and egg involved. I can’t disagree with people who say it would be useful, and I wouldn’t object if Kicad supported it. Of course, it is not me who needs to be persuaded, it’s the dev team
I understand eschema is being overhauled as we speak, so now would be a good time to get ideas considered.
The theoretical aspects pique my interest. The diff/merge done by tools like git is primitive, it just compares text line by line, it has no knowledge of the syntax or even what type of data it is. Yet, that method still works quite effectively for software. So the questions are why is that, and could a similar thing be done for hardware designs?
I have some ideas. I will have to think on them while I watch the football.
Collaboration on Eschema should not be too difficult to arrange on a per sheet basis, as Eschema provides quite a nice set of hierarchical tools, and the sheets are in separate files.
I’d be very interested in this as well. I’d think one would want a graphical diff, though, which would really be a separate tool. Something to compare changes between schematic files in a graphical manner.
However, I believe that git allows the user to supply a “merge driver”, which replaces the built-in line-by-line merge. So, in theory, it would be possible to write a program to merge KiCad schematics (or another one to merge KiCad PCBs) which could be used as a “merge driver”. This could be a separate program and wouldn’t have to be part of KiCad.
As for the schematics, it would be great if someone would build binaries from plotkicadsch. Then the rest of the work flow would be practically same as above. Another option would be if developers implement command line interface for eeschema, which has been proposed before https://lists.launchpad.net/kicad-developers/msg06052.html
This coveres only diff functionality, which is based upon svg files. Merging is completely different beast as @bobc already pointed out so I am not even thinking about it.
As for development, concurrent development is doable in eeschema if you limit yourself to separate hierarchical sheets. I don’t know how the pcbnew workflow looks like, but I’d like to hear some experience.
I have done a ‘Visual Diff’ for PCBs. (https://github.com/Gasman2014/KiCad-Diff) It takes commit references and performs a visual diff between them (or between current version and commit reference). The output is presented as a webpage, split by layer with the differences highlighted in red (removed) and green (new). Happy for anyone to come up with a less garish .css!. To make a meaningful text diff to back annotate which actual component has changed would require a lot more work. I think you could do it by parsing changes in the s-expression back up to the source component in the tree.
If there was a python interface to eeschema, it would be easy to do the same for schematics. I have tried to do this using janvila plotkicadsch but with limited success (plotkicadsch is still in development). I have only got neo900 to run on Linux.
I was about to suggest something similar with KiCad. It should be possible without big issue to work in separate schematic pages. I believe only that schematic page file will change.
One thing is basic version control. There is a lot of internet sources available to get you up to speed.
What is the VCS workflow with KiCad is another thing. As already mentioned in this thread take a look at Massaging your git for kicad.
And even when using version control with KiCad things are quite different if we are talking about one man band project or a team project.
In one man band projects, you don’t really need any special workflow. Pick files which should be under VCS and commit them (project-cache.lib should be under VCS). Until there are good diff tools available for your platform this is about it. If you feel brave enough you can integrate any of already mentioned diff solutions so you easily can compare revisions.
With team projects the main issue is eeschema libraries. There are a couple of setups that work:
each team member has exactly the same libraries, in the exactly the absolute path on his/hers system and in exactly the same order. Obviously this works only if everybody has the same platform (Win, OsX, Linux distro). Even if this is the case I would not recommend this setup.
each team member has exactly the same libraries, somewhere on his system and you use environment variables to resolve relative path (Environment user-defined variables: how to use them?). This is a better solution, but it requires some manual editing of .pro and .sch files.
each team member has his/hers own libraries. If helps if these libraries overlap. An example of this would be official KiCad library with user appended symbols. Also using enviroment libraries like in 2. is preferred. Additionally for this setup to work you have to manually edit .pro and .sch to place the project-cache.lib on top of the library list. WARRNING: this is somewhat unsafe procedure, but if everybody is aware of this it works quite nice. How this works: when team member A puts symbol X in the schematic, the symbol is also copied to the project-cache.lib. Once team member B edits the new version of schematics, Kicad grabs the symbol from the project-cache.lib, sot team member B does note need to have the same schematic libraries. Caveats:
nobody ever edits the project-cache.lib
if you want to change symbol for one part, but there are two or more parts in schematics you have to delete the part. Create a new symbol for the part in the user libraries under a different name and place it in the schematics.
With 1. and 2. you will quickly figure out that having the libraries under VCS is a must. With 3. this is not strictly required but it helps a lot.
Disclaimer: I’ve tried 1. and 2. but I’ve quickly abondoned the setup as it caused a lot of headaches. Since then I’ve done three projects using setup 3 and they did not have any major issues.
Create your project as normal, or use existing project
cd to project folder and type git init
Add files with git add <file> or git add *
Commit to repository with git commit -m "message"
That’s all the basics, for 3 & 4 and most other regular tasks I normally use the GUI, type git gui. In Windows git commands are available in Windows explorer, so you don’t need to use command line.
Whilst Git is an excellent tool, it does have a steep learning curve to use fully (https://xkcd.com/1597/) If you do any software development then learning to manage Git is probably a good investment as it is one of the most widely adopted SCM tools. There are some good graphical git tools out there too - but git on the command line is often necessary and a tricky beast. One of the advantages of Git is lightweight branching and merging. Branches are obviously useful in code development and useful for development of alternative versions of a design. They make it easy to try new variations with the ability to back out your putative design to where you were before. The ability to merge though is more of a problem - whilst it is great for software, merging is less useful for hardware projects - reviewing a text merge of your schematic or pcb layout is problematic at best, meaningless at worst.
Git is certainly not the only show in town - @Andy_P mentioned SVN which is another excellent choice and one which is generally considered a bit easier to learn. It is a centralised VC system (i.e there is one true master and a client - server setup ) and is not a distributed, peer to peer system like Git - this may or not be an issue depending on your use case and how you plan to deploy it. There are many others - CVS, Mercurial, Perforce etc
I would also highly recommend having a look at Fossil - www.fossil-scm.org - which is another but less well known distributed VCS. This is a single, small binary (< 3MB) - available on all platforms and is very easy to deploy and use. It is free and open source. It is very well supported by the author DR Hipp who is also the author of SQLite. SQLite developers use Fossil-SCM as their VCS of choice so, although it is less well known, it has a good pedigree. It is also under active development and has a supportive user group (which, as you know, count for a great deal!!).
For electronic design it is an excellent fit as it does all the SCM version control stuff but additionally has a built in bug tracker, wiki and tech notes sections which make it very simple to keep all your project documentation in one place, cross referenced and easily presented. The bug tracker can be used to link commits to specific ECOs. Add all your datasheets, design notes, project libraries etc to the checkout and commit away. It is very easy to use & has an inbuilt web server which provides an easily accessible GUI.
Only because people are not prepared to read documentatios/ learn the ■■■■■■■ command line. (I hate guis. Well i am using unix for 12 years now. Never going back to a operating system with a weak command line.)
Whether you find Git straightforward or not rather depends on your background, approach and needs. If you are a programmer, especially dealing with anything open source you have pretty much got to know Git and in some depth; you are probably using for other things all the time and it is or becomes almost second nature. Git is not too difficult when used for your own projects but the complexity increases when you start to clone, push stuff back and then put in pull requests. If you do that all the time, it becomes much easier and familiar but for a lot of people wading through it for the first few times, this is where it starts to get a bit confusing.
If you have used other versioning systems - esp non-distributed systems like SVN there is definately a different approach needed and you do need to think about Git in a different way. This might add to the confusion for those who think they already understand VCS and come unstuck when they first try Git.
The point is that there is an investment in time needed to learn anything - Git is no exception - if that is central to your work then it is obviously well worthwhile. I don’t do any programming or electronics at all in my day job so that investment is entirely from my spare time. If you are trying to learn Git to manage something at the periphery of your main interests and then don’t use it very frequently, you might be forgiven for taking the view that wading through a big manual to do something fairly simple is too big an ask. Its a bit like learning vi - if you use it all the time, then the shortcuts available can save an enormous amount to time - but nano/pico does a useful job for the those where the payback in terms time saved /time spent learning is not worthwhile. It’s that shallow learning curve again…
Anyhow - I really quite like the command line for all sorts of things and usually have a terminal open somewhere - but I wouldn’t want tot try to layout a PCB with it alone - after all, Gui’s do have their place …
