Revision control app macro (release)

[laukejas]

Hi,

Like many of you, I use SOLIDWORKS at home for my personal projects. Since I don't have PDM, and 3DEXPERIENCE is still a mess, I decided to throw together a very simple revision control app (macro). Took me a grand total of 2 days. Since it seems to be working fine, I thought I'd share it with you. Feel free to modify it as per your needs.

Purpose:

This app is intended for a simple version control of parts, assemblies and drawings. It allows you to create multiple revisions of your document, easily switch between these revisions, and lock a particular revision from any further changes by setting it to Released once it is ready for exporting/printing/manufacturing. This app achieves it by saving versioned copies of your document to a repository which is located in the hard drive in a directory of your choosing, and storing revision data in document's Custom Properties.

Benefits:
-No more file mess when trying to version them (myPart, myPartV2, myPartV2_1, myPartV2_1_final, myPartV2_1_final_alternate...)
-Clear and intuitive way to bookmark your current design before making major changes;
-Replace one version of document with another without breaking references in assemblies and drawings;
-No more accidental overwriting of your files - every copy is safe in the repository for retrieval when you need it.

How it works:

1. App creates and uses three Custom Properties - ID, State and Revision:

ID is the unique identifier for the document, generated from a random number. All revisions of the document will retain the same ID. It is used to prevent file name collisions in the repository by appending that ID to the file name when saving it in the repository. This might be important if you have two files from two different projects that have the same name.

State is the working state of the current revision. There are two right now - "In work" and "Released". "In work" means that the current revision is open to make any changes. "Released" means that the document is now read-only and cannot be modified anymore.

Revision is the version of the document. By default, all new parts are assigned A.1 revision. When new revisions are created, they can be incremented in the major part (B.1, C.1, etc.), or the minor part (A.2, A.3, etc.).

2. The document you are working with is always the main source of truth, so your normal SOLIDWORKS workflow stays the same. When you save the document, it is only saved to your project folder. If you decide to release the current revision, create a new revision, or revert to a previous revision, a copy of your current document is made inside the repository, but all the references still point to the original document. File name of this copy is made from the ID, Revision and the original document name (for example, 51668462_A.1_MyPart.SLDPRT). But you don't have to worry about this - the file you are working with will retain the name you created.

3. If you decide to revert to an earlier revision, your current document is then replaced from the repository. File name and location remains the same (MyPart.SLDPRT), and references in open documents are automatically updated. Meaning that if you revert from revision B.1 to A.1 in a part, and then switch back to an assembly or drawing, it will display the A.1 revision. For all intents and purposes, you can think of this as replacing the contents of your document.

User interface

Very simple



How to use it:

Set up: open the app macro (SOLIDWORKS -> Macro Toolbar -> Edit Macro), and at the top of the code, specify the path to where you want to keep your repository. By default it is "C:\Repo". Save the macro. I recommend assigning it to a button on the Taskbar, or a keyboard shortcut.

1. Create a new document and save it on your hard drive, or open an existing document.

2. Launch the app like any other macro. If you are using it for the first time on that document, it will generate appropriate Custom Properties, create revision A.1, and set it's state to "In work". If you have used this document with this app before, it will read it's Custom Properties, display the current Revision and State, as well as read the repository, find other revisions of this document (by it's ID), and display them in the drop-down list.

3. Do some awesome modelling. App does not have to be open - you can close it and re-open at any time.

4. When you are satisfied, click "Release revision". Your document will be set to Read-Only, and a copy of it will be saved to the repository. This Read-Only lock is meant to prevent accidental changes to a revision that is already confirmed, but it can be disabled in the macro code (not recommended).

5. If you need to make further changes after the revision has been released, you need to create a new revision. Choose whether the new revision should increment from the current one by the major or minor part (from A.1 to B.1 or to A.2), and click New Revision. The old revision will be saved to the repository if it is not there already, and a new one will be created with the "In work" state.

You can also create a new revision without releasing a current one. Just click New Revision. The current revision will still be saved to the repository in the "In work" state, and a new revision will be created.

6. If you want to revert to a previous revision of your document, select the revision from the drop-down list, and click Restore Revision. Your current document will replaced in-place with the appropriate copy from the repository, and all references should be updated. If the revision you loaded is "In work", you can just continue working on it as usual. If you loaded a "Released" revision, you will be unable to make any changes to it. If you want to continue work from that version, click New Revision.

Please note that the document is only saved to repository when you click New Revision or Release Revision, or Restore Revision. There is no automatic saving of the document to the repository when you click Ctrl+S.

Pro tips:

-Since Revision and State are saved as Custom Properties in your document, you can use them in a drawing via Notes -> Link to Custom Property, or in BOMs.

-You can customize the name of the Custom Properties that this app creates, in case you are already using default names for something else. Check the constants at the top of the macro code.

-On Parts, can add a Boss Extrude/Cut feature of a Sketch Text that is linked to the "Revision" Custom Property, to have a physical watermark of the revision on one of the Part's faces. I use this a lot when prototyping 3D printed parts, to be able to track which printed part represents which revision. I am including a Library Feature of a Cut-Extrude with a sketch that is set up like this, with a text font and size that should print clearly enough on most 3D printers with any settings. Saved in SW 2021. Adjust as needed.

Limitations:

-I have only tested this with Bottom-Up strategy projects. I have no idea how well this revisioning system is adapted to Top-Down, as well as things like Save Bodies, Insert Part, Derived Part and so on. Versioning in such cases is very confusing.

-I am not yet 100% sure that all the references to the document will be retained when it is replaced with the copy from repository, since SOLIDWORKS documents also have their internal IDs. If you know how to use ModelDoc2.Extension.SaveAs3 API call to make a copy of the active document with the same internal ID, let me know.

-If repository is in the network directory, and shared between multiple users, there is no reservation lock check. Perhaps this could be implemented, turning this macro into a mini-PDM, but I don't think it's worth the effort right now.

Known bugs:

-Sometimes when launching this app, it throws "ActiveX component can't create object" error. It's rare, but still happens. No idea why, all references seem to be fine... If anyone knows, please do tell.

Disclaimer:

I have tested the app and it seems to be working fine, but I haven't checked all possible workflow combinations, so there might be some bugs. Consider this a Beta release, and make backups of your projects so you don't lose your work!

To-Do:

-Add revision comments;
-Add multiple repositories (repository per project);
-Add "preview revision" button to check a revision without replacing anything;
-Add optional automatic file saving to the repository when document is saved normally (CTRL+S);
-Add detection and disabling of the app if a repository document is opened directly (currently can cause file name corruptions if any buttons are pressed);
-Make app settings editable in the UI (settings persistence);
-Prevent repository copies from appearing in SOLIDWORKS Recent Files list;
-Implement ID checking of the repository files when creating new ID to prevent accidental random number collision (astronomically small chance, but still);
-Your suggestions...


Let me know what you think. Like I said, I threw it together in 2 days, so it might have bugs. If I find any and fix them, I will upload updated version here too. Feel free to share suggestions on how to improve it as well.

Waiting for comments

P.S. Before downloading, check posts below, I will post updated versions there. Not sure how long I can continue editing this original post and adding new files to it.

[AlexB]

This is fascinating... like a PDM Standard Lite.

I am also curious how this would affect a more top-down modeling structure but this is a really cool idea for a macro project. I'll definitely play around with it to see how it works in different scenarios.

[laukejas]

This is fascinating... like a PDM Standard Lite.

I am also curious how this would affect a more top-down modeling structure but this is a really cool idea for a macro project. I'll definitely play around with it to see how it works in different scenarios.

Thank you! I am not exactly sure how traditional revision control systems (like PDM) handles revisions with top-down. I tried testing revisions with top-down on 3DEXPERIENCE, but I don't think it handles top-down at all


Release V2

Changes:
-App now monitors document changes - no need to close and re-open it anymore to latch on the active document.
-User can now Preview selected revision from the repository (read-only) before committing to restore it. Previewed file needs to be closed before restoring.
-If user opens any file from the repository (either with Preview button, or manually), app controls grey out to prevent messing up these files.

User Interface:



Known bugs:
-Still the random "ActiveX component can't create object" error...
-App doesn't detect when user closes all documents, and still shows last document info, unless another document is opened. This is because I can't seem to implement proper file close event firing. Yes I know of that article Artem made (https://www.codestack.net/solidworks-ap ... ose-event/), but it is just so damn complicated for a simple notification...

[Koen88]

Haven't got a need for it. But very nice work !

[bentlybobcat]

Very nice work.

[doobes]

Excellent

[.Pack]

Amazing!

I've looked for this for a long time without resorting to a solution like PDM.

But here it didn't work
When I click "New revision" or "Release revision" the file is not saved in the Repo folder
I ask to debug and an error appears on the line:




Can you tell me what could have happened?

[AlexB]

Amazing!

I've looked for this for a long time without resorting to a solution like PDM.

But here it didn't work
When I click "New revision" or "Release revision" the file is not saved in the Repo folder
I ask to debug and an error appears on the line:




Can you tell me what could have happened?

IModelDocExtension.SaveAs3 was introduced with SW 2020, are you using an earlier version than 2020?
If that's the only issue, you can try replacing it with SaveAs2:

swModel.extension.SaveAs2 path, 0, options, Nothing, Empty, Empty, errors, warnings

[.Pack]

IModelDocExtension.SaveAs3 was introduced with SW 2020, are you using an earlier version than 2020?
If that's the only issue, you can try replacing it with SaveAs2:

swModel.extension.SaveAs2 path, 0, options, Nothing, Empty, Empty, errors, warnings

I'm using SW 2019.
There's the problem.

I tested it with SaveAs2 and it worked fine.

Thank you very much!!!!!

[laukejas]

Hi guys, after some time I returned to this macro app, found some bugs, things to improve, etc. So here's version 3.

image.png (11.22 KiB) Viewed 7927 times

Release V3

Changes:
-It is now possible to use the app for a component while editing it in-context in an assembly.
-App now correctly detects document changes, as well as when all documents are closed.
-UI has been renewed, showing the title of the document it is controlling to reduce confusion, as well as the directory of the repository.
-All Released documents are made Read-only, all their external references are locked (configurable), and Freeze Bar is used to freeze the whole feature tree (configurable). This should help with Top-Down designs.
-However it is possible to force a released version back into In-Work state through a dedicated button.
-It is now possible to quickly change repository directory, and this setting is persistent. This should be useful if you want to have separate repositories for each project, so they don't mix.
-It is now possible to delete all version tracking information for a part, to reset it back to A.1 with a new ID in the repository. You can also clear out the entire repository with another button.
-Names of the Custom Properties, and the values ("In Work" / "Released") can be changed for localization.
-Major refactoring. Should be much easier to read through the code if you want to customize the app per your needs.
-Added a test suite, current coverage around 80% (most untested stuff is in the UI, which is a major pain to test automatedly in VBA editor). If you make some changes, and want to make sure nothing in the app is broken, run Modules->Tests->TestAll. Prepare a test part (any part) and any assembly (it that contains the part), and run it. Make sure you edit the path to these test models at the top of the Tests module.
-Renamed the app to "Version control app". Someone told me this is more accurate.

Bug fixes:
-Previously the app would not detect when all documents are closed, and show info for the last one. It is fixed now.
-Sometimes the app would leave the Released parts in a weird state, and be unable to return them to In Work. It shouldn't happen anymore.

Known bugs:
-When you Release a component that is edited in-context in an assembly, for some reason SW does not roll the freeze bar on it's Feature Manager Tree. I am using featMgr.EditFreeze2 (swMoveFreezeBarToEnd ) and it returns no errors, yet fails to roll the bar. If anyone knows a fix, let me know. To avoid this bug, just open the part and then release it.

Compatibility:
-I checked and I think that all the API calls should work with SW versions as early as 2019, but I haven't tested it. If you find something not working (or if you need this app running on even earlier versions), let me know which API calls throw an error, and I'll revert them to earlier versions.

Notes:
-Settings can be found in Modules->Constants.
-With default settings, the app will lock all external references when document is set to Released. Make sure you understand this, and change it in the settings if you don't want that.
-Run this macro via the Core.main() (if you make a Macro Button for this app, make sure you select this method as the entry point)

Fun fact:
-The whole reason why I made this macro app is because I tried 3DEXPERIENCE for Makers, hoping to get version control for my hobby projects, and after encountering numerous bugs, crashes, corrupted data, failing to save, failing to retrieve, throwing error messages at me all the time, - I thought to myself - come on, how hard can it be to code a simple CAD version control?

I haven't tested it very thoroughly yet (except for the automated tests), so if anyone has any problems, let me know. And please back up your data, just in case

P.S. If you are using this app, I would recommend checking this box in SW Options so it doesn't bug you about re-saving Released docs. This macro app already saves them automatically just before setting them to read-only.

[mgibeault]

Very good work, thank you!

Maybe you could implement a method to have the Repo as a directory relative to the part's directory?
For example, our structure is like this:
-Project
--CAD
--Repo

This should work:

Code: Select all

'Debug.Print swModel.GetPathName
RepoFolder = Left(swmodel.GetPathName, InStrRev(swmodel.GetPathName, "\") - 1)
'Debug.Print RepoFolder
RepoFolder = Left(RepoFolder, InStrRev(RepoFolder, "\"))
'Debug.Print RepoFolder
RepoFolder = RepoFolder + "REPO\"
newFolderPath = RepoFolder + newSubFolderName + "\"
'Debug.Print "Path: " & newFolderPath
newPath = Strings.Replace(newFolderPath, newName, vbTextCompare)
'Debug.Print RepoFolder
If Dir(RepoFolder, vbDirectory) = vbNullString Then
    MkDir RepoFolder
End If
If Dir(newFolderPath, vbDirectory) = vbNullString Then
    MkDir newFolderPath
End If

[laukejas]

Very good work, thank you!

Maybe you could implement a method to have the Repo as a directory relative to the part's directory?
For example, our structure is like this:
-Project
--CAD
--Repo

Sure, this can be done. But what would be the best way to switch between this and the default (persistent repo dir) behavior? Because each user might want that repo to be in a bit different folder above the part files. I am not entirely sure how to setup this behavior without having the user to explicitly write folder structure in the macro.

[mgibeault]

Sure, this can be done. But what would be the best way to switch between this and the default (persistent repo dir) behavior? Because each user might want that repo to be in a bit different folder above the part files. I am not entirely sure how to setup this behavior without having the user to explicitly write folder structure in the macro.

Yes, you could have the two options (one folder for all projects or one folder per project) and the user has to comment-out the correct one.
I think an "ARCHIVE" folder within the current folder would be the most logical;
-Project
--CAD
---ARCHIVE

[laukejas]

Yes, you could have the two options (one folder for all projects or one folder per project) and the user has to comment-out the correct one.
I think an "ARCHIVE" folder within the current folder would be the most logical;
-Project
--CAD
---ARCHIVE

Hmm, okay, that could work. So, you're suggesting the archive would be one folder up. I wonder if that is where most users would want to store the archive. Also I am not sure how reliable this would be if other users like to make more nested folders inside the CAD folder. For example
-Project
--CAD
---Drawings
---Assemblies
----Sub-assembly

And so on. They would probably still want to have a single archive, not a bunch of archives in each folder.

What is the reason you suggested this automatic one-level-up archive folder idea? Do you switch between different projects often, which would make switching archive directory manually inconvenient? I'm just trying to gauge how to best define the use case, maybe we can find an ideal solution here that would fit everyone

[mgibeault]

Hmm, okay, that could work. So, you're suggesting the archive would be one folder up. I wonder if that is where most users would want to store the archive. Also I am not sure how reliable this would be if other users like to make more nested folders inside the CAD folder. For example
-Project
--CAD
---Drawings
---Assemblies
----Sub-assembly

And so on. They would probably still want to have a single archive, not a bunch of archives in each folder.

What is the reason you suggested this automatic one-level-up archive folder idea? Do you switch between different projects often, which would make switching archive directory manually inconvenient? I'm just trying to gauge how to best define the use case, maybe we can find an ideal solution here that would fit everyone

Yes, one "Archive" per project.
I think what would work better is if the "Archive" folder was inside the "CAD" folder.
We decided several years ago it was way more convenient to have all SolidWorks files for a project in one folder; that way there are some convenient features that work better (opening a drawing from a part/assembly mainly).
As probably a lot of us, I may work for several weeks on one project. But another day I would work on 10 different projects. It has to be automated otherwise it's will be a nightmare.

[Kn1ght]

Hello!
Great app, but i found error in sorting version information.

sorting.jpg (7.18 KiB) Viewed 6602 times

Therefore, the maximum version number can be 10, after which the counter does not grow (since it considers that the 9th number is the last one in accordance with the sorting) and overwrites the last 10th file.

Dirty solution:
in ActiveSwDoc replace in GetNextVersion function

Code: Select all

GetNextVersion = CStr(CInt(latestVersion) + 1)

to

Code: Select all

GetNextVersion = CStr(CInt(currentbranchVersionsList.Count) + 1)

This doesn't fix the sorting, but it does allow you to create any number of versions.

[sloworks]

Hi,

excellent stuff! Thanks!

Couple ideas:

1. All of us do not use "2-level revisions". I mean, I would like to just have revisions like "A,B,C..." or "1,2,3...". Or at least revision should be written to 2 different custom properties, so I could use only the 1st part of it (e.g A,B,C...) in drawing.

2. How about support for configuration specific properties...sometimes we need different item no. for different configurations in model and also revision should be per configuration.

[laukejas]

Hi,

excellent stuff! Thanks!

Couple ideas:

1. All of us do not use "2-level revisions". I mean, I would like to just have revisions like "A,B,C..." or "1,2,3...". Or at least revision should be written to 2 different custom properties, so I could use only the 1st part of it (e.g A,B,C...) in drawing.

2. How about support for configuration specific properties...sometimes we need different item no. for different configurations in model and also revision should be per configuration.

Thanks for your suggestions! I am currently on other programming projects, and don't know when I'll be able to come back to this little side project and fix the bugs and implement stuff that you and others suggested. I hope I'll find time for it.

1. This is a great suggestion, and indeed there are several different revisioning schemes like the one you suggested. I would like to make this configurable, but it would require rewriting a good deal of the macro to make it compatible with these schemes.
2. I have considered this, but the issue is storing and replacing revisions in the repository. If there is one revision per file, there's no issue, macro saves the file to repo when creating new revisions or replaces the original file from repo to switch to another revision. But if different configurations have different revisions, how would macro save/load them to/from repo? After all, configurations share the same file, same features, same dimensions. If, for example, in configuration A you Release revision 1, but in configuration B you create a new revision (2) and delete a feature, you will have broken released revision of configuration A, since features are still part of the same file. As you can see this breaks the trust that this whole macro is about. If you have any suggestions on how to solve this, I would love to hear it - it would be great to have individual revisions for different configs, but I just don't know how to implement that.

[AlexB]

If you have any suggestions on how to solve this, I would love to hear it - it would be great to have individual revisions for different configs, but I just don't know how to implement that.

The way that PDM does this is to load the latest referenced version and hope for the best. There's no good way to handle multiple references to different versions of a component in the same assembly.

[laukejas]

The way that PDM does this is to load the latest referenced version and hope for the best. There's no good way to handle multiple references to different versions of a component in the same assembly.

That sounds more trouble than it's worth... I suppose the "easiest" way to version configurations without such issues is to create a derived file referencing a configuration (new part file and then Insert Part, referencing a specific config from the original file), and then version that derived file instead. Benefit here being that you can lock Insert Part external references in that derived part and therefore ensure correct geometry. Downside of course is the headache of creating these extra files and no easy way to switch configurations between them in assembly. I think this is how 3DX works under the hood (CAD Family (master file with configs) -> Physical Product (derived file with specific config). My macro should be compatible with this workflow as well as it is right now. But yeah, SW isn't really built with this in mind. I think this issue is also very similar to versioning files in Top-Down design. I wonder what would be the ideal solution if we had a chance to make a new CAD software from scratch.

[sloworks]

Hmm. One common revision for file to handle saving/restoring to/from repository. And then "subrevisions" for configurations and when one of those change, also the common revision changes? What am I missing, seems too simple?

[jcapriotti]

Configurations are a sticky issue for revisions. For us they can represent a family of parts each with their own part number. But we can also have some that are for reference in a drawing. The sheet metal flat is a good example. So do you revision those as well? Today we revise all of them together so they are always the same letter.

[laukejas]

Configurations are a sticky issue for revisions. For us they can represent a family of parts each with their own part number. But we can also have some that are for reference in a drawing. The sheet metal flat is a good example. So do you revision those as well? Today we revise all of them together so they are always the same letter.

Good point. I think the issue is that there is no distinction between the two in SW. It should be two separate things - physical products, or an alternative representations of a physical product.

[jcapriotti]

Good point. I think the issue is that there is no distinction between the two in SW. It should be two separate things - physical products, or an alternative representations of a physical product.

I think I had a really old enhancement idea I submitted to have the ability to define different configuration types with different settings (Part number, reference use only, etc.) I think we got the derived configurations that kind of did some of that but not fully.

Today we somewhat handle it with a custom property editor that looks at configuration names for certain suffixes that we have standardized. The configuration name starts with the part number, then adds a suffix if needed for different cases.

[laukejas]

I think I had a really old enhancement idea I submitted to have the ability to define different configuration types with different settings (Part number, reference use only, etc.) I think we got the derived configurations that kind of did some of that but not fully.

Today we somewhat handle it with a custom property editor that looks at configuration names for certain suffixes that we have standardized. The configuration name starts with the part number, then adds a suffix if needed for different cases.

image.png

That is a neat workaround. I might actually borrow the idea for my projects too. But as far as revisions go, I still don't know of any non-messy solution...

[sloworks]

That is a neat workaround. I might actually borrow the idea for my projects too. But as far as revisions go, I still don't know of any non-messy solution...

Still think this would work:
One common revision for file to handle saving/restoring to/from repository. And then "subrevisions" for configurations and when one of those change, also the common revision changes.

[JoshuaDeeMan]

This looks great. I work for a small company as the sole engineer and we don't have a PDM currently so I think this will be hugely helpful as I try to bring order to revision control.

I downloaded V3 first and can't get it to run. I tried debugging and got a compile error "Sub or function not defined" and it highlighted "SetAppEnabling" on the MainForm.

I tried the other versions to see if they would work and both of them seemed to do fine.

Thanks in advanced!