I’ve recently written a post on the SolidWorks forum trying to answer the question of a VCS usage (Version Control Systems) such as Subversion of Git with SolidWorks files, principally as a lightweight alternative to SolidWorks PDM. I duplicate the post content here to help even more users.
Be careful: This article deals with SolidWorks, the Mechanical CAD software, not SolidWorks PCB which is its Electronics CAD cousin.
SVN or Git?
As a mechatronic Engineer, I regularly make board designs, create enclosures and 3D prototypes, and write software programs. I use both SVN and Git, and I think both are fantastic. Collaborating on any kind of projects, seeing what changed and why, and being able to roll back, is something I couldn’t live without.
- Git, as a Distributed VCS (DVCS), brought the ability to work in parallel on a same project or same file, even for huge project teams. It’s a bit more complicated than SVN at start, but the feature-branch workflow with the audit/review step associated to a pull-request are a must. Except that they’re completely useless with CAD files… (no merging capability)
- SVN is a Centralized VCS (CVCS) and is pretty well integrated to Windows thanks to TortoiseSVN, making it user-friendly: you can manage your files right inside the Windows Explorer, which removes the hassles out of VCS – no command line to learn (it’s quite hard to say the same about Git). You keep track of the work all along the design phase, and you know which version you sent to manufacturing thanks to “tags”. The workflow is not imposed by SVN, making it completely flexible and suitable for CAD.
As you may have guessed, I use Git for everything related to writing code, and SVN for everything else.
Which one is good for SolidWorks?
I see 3 major advantages of SVN over Git in a “CAD design” context:
- Better binary files handling.
The xdelta compression algorithm embedded in SVN manages them pretty well, keeping the repository size reasonable. - File locking feature (exclusive locks).
No conflict to resolve. That’s an absolute necessity because conflicts are almost impossible to manage with CAD files – the diff/merge tools simply don’t exist in most cases. - Partial check-out of a repo (or “sub-repo checkout”).
Wonderful if you work with big files but you don’t want to split the project over several repositories.
There are some other advantages (multi-project repo, “by directory” access control, human-readable revision numbers, SVN externals used for libraries, …) but these are the main three. For those who absolutely prefer Git, Git LFS is probably the right way to handle binary and/or large files. If you’re an existing user of an other DVCS (Mercurial, Bazaar, …) I’m not sure if equivalent systems exist.
Important note: with SVN and with Git, you hold a local copy of the project on your computer. It brings the ability to work off-site for mobile workers, but of course you can’t collaborate with remote peers while your offline, neither with Git nor with SVN.
Do I need to push my files over the Cloud?
An important point to remove confusion: using a VCS doesn’t mean storing files in the Cloud! Your IT guy/team will be able to install a Subversion and/or Git server on your organization’s infrastructure without any restriction because both are Open Source and free to use.
If you want open/worldwide collaboration capabilities, then go to a hosting service: Assembla (SVN & Git), A2 Hosting (SVN), GitHub (Git), Bitbucket (Git), or any other.
CAD file comparison
Someone on the SolidWorks forum stated:
For the moment, svn/git can’t make diff on SolidWorks file
Well, Version Control Systems are in charge of storing different versions of some files, and allow you to retrieve them back if needed. VCS like SVN or Git are not in charge of rendering or diff’ing those files. Your CAD tool is.
I know SolidWorks has capabilities to compare two files, I encourage you to test them. Altium Designer (ECAD software) is able to compare two (binary) files, probably like SolidWorks PCB is (it’s based on Altium). If you take some time to integrate your VCS system tightly with your design tools, you would be surprised on how good the workflow could be! I wrote an article about Altium Designer with TortoiseSVN.
Even the MS Office toolsuite (Word and Excel, at least) has an integrated comparison tool! You don’t trust me?
SVN or SolidWorks PDM?
Many users report that SolidWorks PDM is complex, non-intuitive and hard to deploy and manage. I also read that some users may use SolidWorks PDM only at the delivery stage: what if you mess up a file in the design phase?!
PDM is even used by some of you to store ECAD files. Honestly, I don’t understand how can’t it be an absolute nightmare…
To me using a VCS such as SVN or Git is an advantage to using a proprietary solution like PDM:
- The user experience could be shared across professions in the same organization, in particular if they use the same VCS
- File sharing is made easier, between peers and between professions
- Maintenance could be done by a VCS person (no need to have a SolidWorks PDM specialist)
- Do you also use Inventor, Creo, CATIA, Solid Edge or an other desktop CAD tool? SVN works the same!
Because things are not well integrated between SVN and SolidWorks (yet), I’m thinking of writing a piece of software myself. Are you interested? Feel free to write a comment in order to get in touch!
We would be interested in some sort of Solidworks metadata management using svn. We currently use svn to version and archive ECAD (KiCad), MCAD (Solidworks), documents, and of course software code. As you point out, the fit with Solidworks is poor.
Hello Justin,
We have been using SVN for file sharing and revision control for almost 15 years, I would say. Stating with dwg files and Alibre files, and then moving on to SW files when we bought the licenses.
We handle everything through Tortoise wich works fine but does demand a little overhead in terms of how many clicks are needed.
I´ve never used Solidworks PDM but did try and used for a limited time one product from a (of all companies) SW partner called DDM. If a partner goes ahead and develops his own solution maybe SW PDM is not all that good, haha. If you decide to go ahead I would encourage you to contact them for a demo, really nice people.
Following your own reasoning myself, I did look at SharpSVN as a way to ease the integration between svn and SW but I am not a C# developer and mostly use SW macros developed by other people so at this time I am actually doing nothing of this.
Going back to our own experience and what I saw when using DDM´s PDM, the thing I miss most is the ability to perform searches on the repository based on metadata (or properties). Since this is something not implemented on SVN as an “SQL” search, in case the user wants to search for parts based on the same materials they use, SVN is not able to do that in real time once the repository starts to grow (our own repo is now bigger than 100 Mb). Also once the repository starts to grow, and users start to make mistake, it is likely – as it happened to us – the repo might break. Actually it keeps working but you lose part of the revision history.
Lastly, what is really a big difference is the “revision” concept. As defined in SVN a new revision means how the repo is at some state in time, while in engineering the revision refers to a specific part or assembly. I have not used Altium, how do they manage it ?
Look forward to hearing your comments. Regards.
Hi Jose,
Thank you for jumping into the discussion. All of your messages really encourage me to continue the development of a project around SVN and Solidworks.
You’re right about the distinction between “revisions” and “releases”. From what I’ve seen so far, Solidworks PDM is (almost) never used for the “revisions”, only for the “releases”; which I find quite not good. The design phase is a complex process that really deserves some sort of revision tracking.
SVN is great at managing revisions, and it offers some solutions to handle the releases as well. One of them is called “Tags”. Or releases can be managed outside of the revision system, that’s what software developers do.
You’re stating: “in SVN a new revision means how the repo is at some state in time, while in engineering the revision refers to a specific part or assembly”
Well, no. I mean: not really. Revisions in SVN are what you decide them to be!
When you say “specific part or assembly”, do you refer to the “release” I’ve mentioned above?
Finally, I agree with you on the “navigation” and “search” features. Solidworks PDM includes things like that, which is cool.
SVN or any other VCS can’t handle that because it’s not their job. We have to build something on top of the VCS to get these features. By the way, the “repository browser” offered by TortoiseSVN is an extended feature compared to what’s standard in SVN.
Justin
Definitely something like this would be needed. I’ve used GIT in the past for software and I’ve liked it a lot over CVS, but I understand, SVN could be better for binary files. I don’t have personal experience on SVN. But some help for revision control handling is definitely needed.
Please let me know if you do a plugin for SW. Ive used SVN with cad systems back in my AutoCAD days and like it a lot. When i switched disciplines and moved from 2d to 3d i was prepared to bring it with me but we found grab cad which worked great for the last number of years. Sadly the service has gotten real flakey and unreliable over the last year and the lack of updates is concerning. Im now again toying with the idea of making my own unless you decide to go for it, then let me know, Id be happy to test or help in anyway i can.
Hello Jakob. I appreciate your support and your feedback about GrabCAD and AutoCAD+SVN.
As for the extension, at the moment I have no more than an idea and few lines of code, which is almost nothing to be honest. I run out of time to go further.
I understand that the project gets some attention so I’m currently evaluating how I can allow more resources on the development. I now have your contact so I’ll keep you posted if things move.
Justin
Hi Justin,
I think that the idea of being able to manage code, ECAD and MCAD inside the same system is a really interesting idea. There is so much design gaps that could be easily avoided by having a common system that allows code, ECAD and MCAD to talk to each other. Some PLM systems already does it but are highly complex and expensive platform to maintain (Enovia, Windchill, Teamcenter for instance) and thus you would receive a lot of interest I think if your are able to come up with a simple solution.
You have to remember thought that PDM is not used solely as a version control software but also and mostly to control the relations between baseparts, parts and assemblies. For instance, bill of materials are created and accessed from PDM as well as all the metadata required to search through the 1000s parts a minimally complex product is made of. Engineering changes and design documentation can also be managed and related to MCAD files.
If a complex assembly is at rev D and an issue come up in field with the revision B of that same assembly, I need to be able to consult that rev of the assembly along with the revision of its sub-parts at the time the assembly revision was released.l, with their respective metadata. The metadata could be the manufacturer and mfg PN of those parts, the material they were made of, quantities in the assembly, etc.
Not that I am a big fan of PDM, I personnally think that the UI is poorly designed and the administration of the vault is way more complicated than needed. But you need to consider that there is a whole team of software developpers and prduct management specialists that has been working on PDM in order to bring where it is and still today to maintain it.
If you come up with any code easing the management of MCAD files with SVN I would certainly be interested to look into it and provide you with constructive feedback.
Regards,
JC
Hello Jean-Christophe and thank you for your valuable inputs.
Of course a Version Control System is not a complete Product Data Management system (PDM). And it will never be, unless developing a complex new layer of software on top of the VCS.
My idea is to keep it simple and flexible – which I think a PDM is not, while getting the most out of the VCS itself (which few of us really do, trust me).
I currently don’t have time to work on my idea, but I keep your contact for further collaboration on that topic đŸ˜‰
Hey Justin,
Thanks for the article. I’ve never used any sort of version control for my company’s Solidworks files, and have pretty much just duplicated all the parts associated with an assembly into separate folders. Obviously, the more nested the assemblies, the more arduous it becomes in checking that references and such are all updated. I will spend sometime checking out SVN.
As for the issue with conducting diffs/merges, I have some ideas. I’ve written a small C++ program that uses the Solidworks API to automate part/assembly creation and drawing, I know at least that actions can be translated and recorded as function calls. As for the files themselves, I’m not sure about the internal representation that Solidworks uses, and how it translates its SLDPRT files.
Anyway, if you’re planning to set up some sort of repo to document this works, I would love to get involved.
Thanks,
Joel
Joel,
Thanks for jumping into the discussion.
SVN externals are a little tricky to manage at first but I would seriously consider them in your case because of the possibilities they offer. You could decide whether to track the latest “shared” part(s), or to stick to the version you define and update your assembly only when you decide.
I’m curious about how you would compare two parts or assemblies through the API. Do you have a code example to share with us? I know Solidworks is capable to do so but it would be perfect if I could have an example that I could derive to integrate into TortoiseSVN! This might be the start of a collaboration work đŸ™‚
My code isn’t anymore complicated than the examples on the Solidworks API docs. If you do a bit digging into the docs, you’ll see that the API can be used to parse out the details for each object. For example, each SLDPRT can be decomposed into properties of the document, features in the feature tree, etc.
If each solidworks file can be translated as such into something that can be diffed/merged, it might work.
Ok I get your point. I will read the docs extensively when I will start writing my own SVN extension.
Thanks.
Hi Justin – great intro to the utilization of SVN for SolidWorks. I utilize SVN currently for version control, but am interested in using it to create a versioned library of common parts for reuse. I’ve been looking into SVN Properties & potentially an API to add searchable metadata – have you done anything similar?
Hi Melanie and thank you for your message.
Versionning a library of parts vs. the project CAD files is actually the same, at least from a file point of view. Where there may are differences is from the linking point of view.
Some of the questions you should find an answer to:
Of course I can’t answer your specific needs here, but I encourage you to take the time to carefully read the SVN documentation and explore how software developers use the tool. For example, the “SVN externals” may help you.
Good luck!
Hi. This seems to be interesting for me as an self-employed design engineer. How do you want to deal with links between parts which are created while designing in context?
Hello Roland,
Thank you for participating in the discussion.
You’re right, from many forum topics people talk about “breaking the links” when using such a solution. For a first attempt I planned to not deal with them at all, I will probably consider this issue only in a second step.
But because you seem to be well aware of the issue, could you please tell me more about those “links”?
Justin
Hello Justin.
That are connections between parts in an assembly or parts to an controlling element, for example from a part which is linked to a sketch in an assembly in which positions for screws are defined. If you are moving a position of a screw in the controlling sketch, this will be modified in all related parts.
They are created by projecting an element from one part to another, creating constraints in a sketch or by importing an part.
At the moment I’m relinking these elements – or just delete the constraints and create new ones. There might be a better way which I don’t know.
Roland
Roland,
I my experience the best way to handle these links is to not use them in any ,,final” CAD files.
If it’s early RnD cad model, its ok. Its ok to work with multibody files.
But at the end of the road it have proven, that making cad files without external references (either part or asy) is much more faster and easier to work with
Thank you for share the information. I will start with SVN to control CAD files. You talk about advance the integration between SVN and Solidworks. I have an interest in this and maybe I can help in the development. If you have more information about this topic share it with us. Thank you again.
Hello Daniel and thank you for your feedback.
Like you I’m convinced that SVN can be the right tool to manage CAD files but it lacks a bit of integration. I’ve started to write an SVN add-in for Solidworks but I’m really new to the Solidworks API and don’t have much time these days to keep going. I’m sorry but I can’t help you more for now.
By the way, what do you expect exactly from such an integration? Is there something missing or not working? Or did you ask just “to ease the process”?
Hey Daniel,
On second thought, yes I can give you advice about versioning binary files: use LOCKS. Because two versions of a binary file can’t be merged together, the exclusive lock mechanism is the way to go to avoid two persons working on the same file at the same time.
As described in a previous article, I encourage you to enforce the “svn:needs-lock” property on every binary file types. This would force your users to “get lock” before working, which would avoid file version collisions.
In the past, “svn:auto-props” should be defined on each user’s computer. Since SVN 1.8, I recommend to define them at the repository root since “svn:auto-props” defined on a folder are propagated to the children folders.
Example of auto-props parameter:
*.doc = svn:mime-type=application/msword;svn:needs-lockMore help:
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html
http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config