I noticed an issue with KiCAD8 lock files. I have things set up so that the project and libraries are in cloud storage that is synced to PC. Apparently if 2 instances of the same project are open on different computers, and then one closes the project it deletes the lock file. This happens while the project is still active on the PC that generated the lock file in the first place.
Is this a common issue and has anyone found a work around for it? Preferably a workaround that doesn’t involve git lol
If you don’t want to use Git, use something else that works like Git. Using a “cloud sync” service to share files that you will have open in two places at once is a recipe for disaster.
Warning about the possibility of interleaved saves does seem like a feature, not a bug.
And dealing with independent edits by multiple people is precisely what version control systems like git, cvs, etc are designed for. Git can be used locally if you want, services like GitHub just make git easier.
No hostnames does not matter. I have consistently have problems with the lock files because I use dropbox. I am the only person who work on my projects on either home or work PC. I never have the situation that both PC’s are active at the same time. Yet I keep getting the lock messages telling me that the other PC has locked the files. I just click them away.
@Operationwinkle Like paul mentioned. Why do you want to deliberately open the same project on 2 PCs at the same time? IMO this is a critical flawd in your workflow. The only program that I know that can do this are those google spreadsheets which can be live edited by several people.
The lock files were deliberately added to prevent people from doing pricesly what you are doing.
If you really need to have more than one person working on the same schematic, use Git and some rules that every person is to stick to their own schematic sheets to prevent merge conflicts. Working on the same board at the same time is simply not possible (that I know of)
I think a lot of the discussion is ignoring the main point here. The lock files are simply supposed to tell a program to open a file in read-only mode or warn the user about the file already being open elsewhere. E.g., If I open the project twice on the same computer, it warns me that the project is already open by “me” at “hostname”. That’s great, working exactly as intended in a QA scenario.
Git and some rules shouldn’t have to be a substitute for a different system with a different purpose that is implemented but doesn’t work as intended. Ideally, the lock file should still do exactly what it’s intended to do, regardless of whether one is using Git or not.
Git/SVN can honestly be quite horrible for KiCAD, because sometimes having rules isn’t enough, and mistakes happen. And when you do end up with merge conflicts they can be really tough to resolve since they aren’t very intuitive to read, unlike code. Git and SVN are absolutely fine if only one person is running KiCAD. I’m wondering, do many firms even use SVN or git with other ECAD software like PADs, Altium or Eagle for short and long(20y+) active projects and products?
Anyway, we did a couple of tests and it worked properly between my PC and another as it’s supposed to. But then with a different PC using the same cloud service that should be setup in the same way created issues. Will do some more testing after midsummer, see if it needs a bug report or not.
Why so fixated on the git/svn part? It’s not the point of the topic in the first place, nor a solution to the issue itself. We can spend all day discussing the benefits and drawbacks of different systems like git or cloud services, but it still doesn’t address the bug which is the actual topic here.
The problem is lock files are not working properly. The question isn’t “What version control system should I force my company to adopt with it’s other version control systems”
GIT works just fine with KiCad. It is not Git who makes merge conflicts, that we do ourselfs. I think the lock files work well provided it goes well with your shared storage location. I heared it works better with one-drive.
Sometimes at work we need to use the same resources/machine at the same time. This is not always possible. At that point verbal communication is all we have. Unfortunately some engineers tent to be ‘special’ and sometimes that result in poor verbal communication.
I was once thinking to use a dyed tin can as a physical token. (can be anything really, a stuffed animal pig, whatever ) The person who has physical posession of the token, is the only person allowed to work on a certain project. When he is done, he may push his work to git. And then he may return the token to it’s default position (hang it back on the machine in question). Goodby merge conflicts and associated issues.
If you really need to work on the same files at the same time: give each person his own Kicad project, let him make one or two schematic sheets, route his part of the board. Than all people can give their finished work to the lead developer who can than merge the lot by hand.
Ofcourse you still need to make some ground rules. Especially for things like hierarchial labels, names and reference numbers.
) The person who has physical posession of the token, is the only person allowed to work on a certain project. When he is done, he may push his work to git. And then he may return the token to it’s default position (hang it back on the machine in question). Goodby merge conflicts and associated issues.