Autodesk Github
Lane Stefano
DWG files are binaries so using a version control system is less than ideal. You would be better off using Dropbox or something similar if you want a zero-effort version system that is distributed. They keep versions for 30 days in the free account or a year in a paid account. DXF is a red-herring in most cases, don't chase that rabbit.
Another thing you could do (I do this for a few clients) is work in a different folder than the archive. When you are ready to commit a version then sync the working folder with the archive. I use Free File Sync but Watch out for Adware in it. I jsut installed v7.5. MalwareBytes said it was ok. It asked me if I wanted Opera browser during the install (nothankyou) but no other weird stuff happened. Looks like they (too) have dropped MalwareForge...er, SourceForge.
Set deletion handling to Versioning and naming convention to Timestamp. FreeFileSync will move deleted files into the provided folderand add a time stamp to each file name. The structure of thesynchronized folders is preserved so that old versions of a file canbe conveniently accessed via a file browser.
The biggest annoyance here is merge conflicts but Git was going to bite you with this anyway. If files are edited in both places the Free File Sync will flag the conflict and you will have to solve that mystery yourself.
If you are part of an industry where people can reasonably expect people contributing to a 'common data environment' to keep transmittal records of when each version of each controlled document was provided to whom, then git maintains that document register in a form much closer to a traditional transmittal or document register.
As noted above, it is worth noting that most CAD deliverables for construction are proprietary binary formats, like your DWGs and PDFs. These do lose a lot of the other potential points of difference of git versus a basic file syncing tool like dropbox. They are not stored in git as efficiently as a text file. They are stored in some sort of special binary blob 'annex'. On the other hand the loss of the ability to confirm who wrote every word on every line of every document is not a reason to discard the other whole of document version control benefits of git over a cloud file syncing service with a single 'current' state. The github desktop client is a pretty good tool for non-technical people to see a list of altered documents between two states of the project history.
At least in construction with the shift to open standards for BIM collaboration between entities using text based ISO standard file formats like IFC we are on the cusp of a future where 3D models in a structured text file are the deliverable contract documents. I for one would like to be ready with a working understanding of how to use something like git to have a cryptographic signature on a commit that defines who is responsible for every element and property in the federated model, with revision descriptions. My brief investigations of this tend to suggest that ifcxml diffs are a lot easier to make useful sense of than ifc. The work to produce automatically validated simple ifcxml files to match ISO 19650 'information requirements' looks like the way a thoughtfully lazy person might want to set something up. As such, there is also some future proofing scope for git as a common data environment for DWGs, even if they are not fully realisable at present.
You may even convince an entire project team to exchange documents in dxf format. Unless you are drafting all the contracts and reviewing their progress claims, that sounds pretty much like sparkly rainbow unicorn territory to me.
Alternatively we could all continue to use dropbox and excel document registers with a scanned signature on the 12 page pdf, to validate who authorised the documents' release, then do all the rest of the document control in jellyware. It'll probably all be fine until someone calls their lawyer. If there is a problem, the jellyware approach just requires endless hours of super fun busy work that should get any lawyer on hourly rates a bit excited. They could even load each milestone into a git repository and have git present the transmittal history to them so they can work out who's dead tree transmittal to attack.
If you want see the changes you need a specialized tool , the only one I am familiar with is Vico Doc Set Manager - -doc-set-manager-/tabid/87528/. I think Autodesk Vault has a plugin for doing this.
If You like just to be able to track the history, move back and forth in time then GIT and Autodesk Vault (since dwg is proprietary Autodesk solutions are usually a first choice) are almost equal. None of them can do the diff of dwg files. Yes, Autodesk product can't do diff on Autodesk files.
Git, when You will get advanced, will allow You to do much more things that Autodesk Vault can do. The most critical thing is "history branching" without which any serious job is impossible. Remember those file "version with something.dwg", "need to try this.dwg" and so on? With GIT you can just use "alternative history".
Also GIT should be configured in such a way so that it would never attempt to do any file modification. I do mention it, because it may be configured to, for an example, change "end-of-line" characters between Linux and Windows. I'm not sure what are defaults, because I always configure it to "don't touch files".
I do use GIT for Autodesk Inventor, LibreOffice and other files. No problems, except large disk consumption and lack of ability to see differences between versions. But what to expect, if You need to keep 50 or more copies to track the history?
Good side of GIT is, that You don't have to have any kind of server to benefit from it. It will keep the history on Your disk and You don't have to share it with anyone. You may, if You like, but You do not have to. This is a low investment starting point which is worth to try. Surely You will find some limitations, but in my case this is a good and cost effective tool.
I'm about to install Visual Studio Add-in Wizards for Revit 2019, 2020, 2021 as per Jeremy's Tammik @jeremytammik post -add-in-wizard-github-installer.html but having trouble launching install.bat file which I found in the latest 'VisualStudioRevitAddinWizard-master.zip' file.
Any ideas of what I'm doing wrong? Could someone explain of how this installation can be done successfully step by step in other words? Maybe I have downloaded wrong files or Visual Studio 2017 was not installed properly?
If you add 'pause' command to the end of the .bat file you'll see an error message perhaps. Would first check that all the file/directory path locations noted in the .bat file are available and can be written to.
I've upgraded my Visual Studio to 2019 and moved downloaded files manually from drive D:\OneDrive\Documents... to the appropriate folders in C:\Users\*name*\Documents\Visual Studio 2019\Templates\Project Templates.
c80f0f1006