It is good that you have a team that is working together. Hold a 'Merge Meeting' - even informally - for each merge - basically an incremental design review. Anybody else working on the same project sends their changes to that person - call them Project Foo Ghod (PFG). In general, a Good Practice is for ONE person to be responsible for a design. Think carefully about how you are concurrently working on a design. ALL changes to a footprint goes thru the FRG.Ĭoncurrent work on a specific project can be a nightmare. They should get the new footprint & add it to the common location. ALL additions to your common footprint library should go thru them. You should have ONE person as the Footprint Release Ghod (FRG). I like the Windows Explorer add-on for ease of use. Subversion will work - it can handle text and binary. A pre-release is something that we might wish to keep around for reference and redlining. We use the tags folder for pre-releases and releases.

So this really isn't 'concurrent' design as such it requires communication between the designers.Īs for folder structure? The usual trunk/branches/tags works, although branching a PCB design as such doesn't make much sense because you can't merge the changes back to the trunk like you can with text files. (subversion can't merge the binary files.) Once you commit your change back to the repo, the lock is released and another engineer can get the lock and make changes.

This prevents someone else from committing a change while you are making changes. When someone wants to work on the design, they have to obtain the lock. All designs are of course working copies checked out from the repo. Each engineer checks out a working copy of the library and updates it as necessary.Īs for designs, since svn (and other SCC programs) don't do binary diffs well, you should take advantage of svn's 'lock' feature. Since you already use svn for firmware, you know the workflow: each engineer uses a working copy of the project, and every time they start to work on the project they have to update their working copies and then commit the changes back to the repo. Working copies are not shared.Īltium Designer already has support for libraries stored in a Subversion repo - they're the svndb libs. We use Subversion for firmware and for PCB designs.

Altium designer tutorial arm