All
I’ve entered a Bug Report suggesting a feature to provide collaboration support.
I envision this as not just the existing Archive (zip), but also handling custom Symbols and Footprints. A feature should bundle everything necessary for another person to begin to edit or review a design, then send back modified files via the same tool. Libraries on both ends would sync - magically. There would be complimentary “bundle” and “unbundle” features.
My request is not particularly detailed as I don’t want to have the discussion bog down in minutia, which I am not capable of arguing.
If you think this has merit, please go to launchpad and vote for it.
Now, I realize that versioning would be nice, but that need not be part of the initial implementation.
For your use case, you can use git, but you must set up your libraries right to ensure they are portable.
What I usually do in these cases is:
Create new git repository at the root folder of my project
Add a libraries folder there
Create a new symbol library specifically for this project, save it in the folder above
Create a new footprint library specifically for this project, save it in the folder above
This is the most important part: add the path to your project as an environment variable inside kicad (Preferences > Configure Paths)
Add the files to git and commit/push often
The person who will review your work, must clone the repository and do step 5. After this git should work pretty well with your project and both can modify safely the project.
Not necessary. There is the automatic $kiprjmod variable that always points to the project root.
There are also two usecases. Viewing of kicad files does not really require anything special. Just ensure the cache lib is included. If the person viewing it has different libs setup then they get the rescue dialog where they simply accept the default.
If the other person should be able to make changes then svn or some other centralized version control system might be the better choice. This allows everyone to lock the file they work on and therefore ensures that you do not need to merge stuff.
Regarding libs: you can either use project local libs as this will not require anybody to setup global libs. (make sure the project local lib tables are under version control)
Or use global libs as usual but this requires everyone to setup the shared libs (share the libs either in the same repo or have a library repo separately. When using git then i would suggest using a separate library repo but include it using submodules)
To be honest i would personally prefer the global setup as it reduces the dangers of getting the same asset in a different state for different projects.
As with all things in life there are trade-offs. The centralized system means you have an easier time maintaining your libs but every new collaborator has some initial work to do.
The same also works with dropbox and similar but there i would suggest to go with a project local setup as it is not possible to roll back the lib to an older state when viewing an older version of the project. (Old version would have the older local libs in that case)
I wasn’t aware of this. It might be because my projects usually have more than one PCB which means that the root folder of the KiCad project is several levels above what I consider my project root folder.
If I use this $kiprjmod environment variable then I have to have copies of my library for each PCB which will create other issues.
With the flexibility that KiCad offers there are a number of different workflows possible.
I for one don’t like the project specific libraries. So for collaboration this requires that everybody has the same set of libraries which are shared throug git. Obviously any new symbols/footprints/3Dmodels have to be added to the libraries before using them in the project. We use similar procedure that KiCad uses with official libraries. This slows the development of the project a bit but on the other hand every symbol/footprint/3Dmodel is properly reviewed before being used for the first time. So if everybody is using the same set of libraries then the collaboration is much much easier.
For ease of collaboration, it would be nice if the new symbols and footprints were created in a Global Lib, then magically copied by the bundling feature to a Project Specific Lib for sharing. The recipient would have new items automatically copied to his/her Global Lib. Updates from any user would then be propagated using this process.
No matter how easy it is to share files there always is the question of how much centralized control do you want for your libs.
One option is that you only allow assets to be used that are verified by multiple people. This means you will need a central (global) lib where no one alone can add assets and it is strictly forbidden to use project local libs (or anything not in this central lib) -> This usecase is quite well-supported right now. Place your centralized libraries into some form of version control system that only allows people to add stuff if others agree (The pull request system of gitlab, bitbucket or even github is one option.) Everyone who needs to collaborate then adds these libs (as read only) to their global library table. (manually via the library manager or you can share a centralized lib table. This of course requires one time setup as already mentioned above)
The other extreme is a free for all. Everyone adds symbols or footprints as they see fit. No one but the current designer is responsible for the asset they add to the project.
With the current feature set of kicad i would use project local libs that are stored inside the project directory. This would remove the need to set up global libs at all (the local libs are handled by the local lib table that is part of the project anyway. Make sure it uses the kiprjmod path variable to make it independent of the users file organization). To share this project simply send a zip archive of the project directory (git or other version control systems could make this more powerful as well)
V6 will bring massive improvements especially to the second extreme as it will embed symbols into the schematic files similar to how footprints are already embedded into the layout file. This will get rid of the strange cache/rescue stuff we have to deal with right now. (And will make collaboration much much easier)
To be honest i see no real benefit to a bundle/unbundle action suggested here. If you want to go the strict route then you can not allow a lib to exist inside such a bundle (as it would be outside the control of the central management)
And with the lax option there is no need to unbundle as you can live with local libs anyway. So could you enlighten me why you think this bundle/unbundle stuff would improve things and if so how?
Rene
I’ve worked in big companies and small proj. I fully understand the issues you’ve described.
Part of my reason for posting is to HAVE THIS DISCUSSION and possibly make KiCad better for it. It would be terrible to have gotten close but not been able to support collaboration.
I do not want to imply that your request is invalid. Just that i have too little information to understand what you really want to solve (Your request sounds a bit like a solution. What is the exact problem you try to solve with it?)
I proposed a feature to aid collaboration. The response was to use the existing Archive/zip feature. I consider Archive inadequate as it does nothing for libs. The subsequent discussion has focused on libs, which are an important part of the collaboration issue.
I still feel there needs to be a way to collaborate via git/dropbox/cloud without having to add manual workarounds. Maybe V6 will fix this with no additional effort, but I don’t want to see V6 miss this goal by some minimal amount for lack of thought and discussion.
worked in small companies and big projects. Therefore collaboration is useful to speed up time to market. Collaboration feature is known as “team pcb” what are several designers working with one pcb same time. Successfull component placement by ratsnest requires always assistance of expert designers and takes a good fraction from time of the board design. The board outline is derived from mechanic cabinet what was designed concurrent to schematic entry. File with empty board outline and netlist is cloned to local copy for all contributers. Divided circuit sections were assigned to the contributors and each start working in parallel with his placements. After typical one day, files were merged. Each contributor exported his placed parts into ascii file what only contains refdes, x,y,rotation. This is equal to a partitial smd pick and place data file. Any of the 4 designers shows a pcb with placements finished for apporx. 25% and each of them in a diffrent corner. A script then simply overrides the x,y,rot for each RefDes from all preplaced files into one for merging. Unplaced footprints snap magically into almost correct position inside a second with each import. 3 contributers speed up design time at least 50% and merged file needs only small corrections. We never tried doing this with traces and we never had more than this simple script support.
What part of the process for collaboration is insufficiently supported right now (be specific as it makes it easier to get to an understanding).
I agree, archiving does not help.
I think it was suggested because the archive plugin linked above right now does the bundle step you requested. (Not the archive button of kicad but the script linked above. That script takes all used library assets and creates local libs from them.)
Agreed.
Workaround for which missing feature? What part of the process do you feel is missing?
