Hello - I’m trying to figure out the best process for handling change management on an interior design project. Right now my plan is to have a .dxf file be the ongoing system of record that will be managed in git, but then used sketchup to make modifications and export back to .dxf.
Right now I’m considering 2 processes for how to handle the work in sketchup.
Each time I want to make a change: create an empty sketchup project, import the .dxf file, make the changes, and then export back to .dxf.
Maintain a corresponding .skp file along with the .dxf file and then export the latest changes to the .dxf file before pushing back into git. This option runs the risk of changes existing in the .skp file that don’t get transferred into the .dxf file.
Any thoughts or input around this would be very much appreciated. Also any suggestions for how to approach change management from a different overall angle would also be welcomed.
So the issue with using git to directly track .skp files is that the model would be added to the repo for each revision commited, and you’d end up with a large repo in a short time. I assume this is why you thought to export to .dxf and version the text file instead?
Would COLLADA be a better format in your process?
I have an idea for a git-like version control plugin. There would be no such thing as merging models - it would only support the ideas of branch, commit and checkout. Commit would save the model and generate a graph of ancestor models with descriptions of changes (entered by the user.) Branching would be supported when opening (checkout) a previous version, then commiting changes. There would need to be a dialog to display the graph of revisions and allow opening (checkout) of files. It’s doable. It doesn’t do anything to solve the file size problem, although zip compression could be used to reduce file sizes after saving. So it’s not exactly version control in the sense that git is version control - it’s really just “save as” with unique id’s, file compression, and a graph viewer.
Another idea is instead of exporting to .dxf, to write an exporter that generates a text file. Then when that tyext file is imported it would recreate the model in a more “SketchUp” way rather than a broken .dxf import. Maybe the format is json,or a custom description language. Maybe the exporter generates a Ruby script that redraws the model. Then you version control the text file using git.
Somewhat related is a version control program that is distributed as a single executable named Fossil. I was also wondering if it could be helpful in writing a version control plugin for SketchUp files.
As Jim says, git is designed for text files where a change causes only a limited part of the file to be different (thus "diff"s between versions). In any more complex file format (especially binary, like encoded videos or SketchUp files), a small change made in the software could cause all or most of the file to be different.
As a consequence, you cannot use "diff"s to understand what is different between versions, you cannot merge differences (because all the file might be different) and the repository size grows quickly.
Using a text-based file format (like ASCII dxf or COLLADA dae) can be a work-around as long as the exporter creates reproducible files (unchanged SketchUp entities are encoded in the exported file in the same order and location and without changes).
There is also a “variant” of git that solves the repository size problem. For example Bup does not add files as a whole but only as chunks and deduplicates identical chunks (that are identical in multiple files).
But when a user has backups (sequential versions or branched) the situation can come up that the user wants to understand/visualize what exactly is different and eventually not only decide which whole file to continue with but also maybe keep part of one branch and part of another branch (=merging). This is still manual effort.
Just want to start by thanking everyone for taking the time to respond. @Cotty I’ll take a look at Trimble Connect but it looks like what it primarily focuses on is version control and after doing a bit more research (I’m in the process of trying to pin down the generally accepted definitions of the different terms), it appears that what I’m really looking for at this point is “change control”. I.E. the ability to easily and cleanly see the delta between to projects or 2 files. For those familiar with the code review process in traditional software development projects, this is the process I’d like to establish in a CAD project.
As @Aerilius mentioned, if one is using a tool like git, an ASCII based file format is needed. This is why I’ve been heading in the direction of storing project files in .dxf format (I’ll go ahead and look into COLLADA/dae as well to see if it offers any advantages).
At this point I don’t have any expectations on finding an ideal solution, so I’m looking at as many different combinations of tools & process as I can, and then will pick the one that has best balance of advantages vs disadvantages.
If you make good use of Components along with a xref manager plugin, then it might make sense to store the components in a repository. That way each change you make to a component could be tracked in git along with a commit message. You could see which files have changed in each commit. It would also keep the repo smaller because only the changed components would be increase the repo size for a commit.
