There is also a “variant” of git that solves the repository size problem. 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).
#Sketchup version control software
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.Īs 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. I was also wondering if it could be helpful in writing a version control plugin for SketchUp files.Īs 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). Somewhat related is a version control program that is distributed as a single executable named Fossil. Then you version control the text file using git. Maybe the exporter generates a Ruby script that redraws the model. Maybe the format is json,or a custom description language. Then when that tyext file is imported it would recreate the model in a more “SketchUp” way rather than a broken. dxf, to write an exporter that generates a text file. 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.Īnother idea is instead of exporting to.
#Sketchup version control zip
It doesn’t do anything to solve the file size problem, although zip compression could be used to reduce file sizes after saving.
There would need to be a dialog to display the graph of revisions and allow opening ( checkout) of files. 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 be no such thing as merging models - it would only support the ideas of branch, commit and checkout. I have an idea for a git-like version control plugin. Would COLLADA be a better format in your process?
I assume this is why you thought to export to.
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. So the issue with using git to directly track.