When developing software, most companies use a version control system such as Git, SVN, etc. Version control makes it possible to distribute work among several people, combine the work, view the specific changes made by an individual, etc. This kind of system is convenient when creating drawings, especially when more than one person works on a single drawing.
OdTfRevisionControl
Teigha has a similar functionality called OdTfRevisionControl for working with .dwg files. OdTfRevisionControl is still under development. The main concept in the version control system is the commit.
The commit adds the latest changes to a repository and saves the state of objects that have been added, edited, or deleted (OdDbLine, OdDb3dSolid, OdDbBlockTable, OdDbDictionary, etc.).
To get started, you need to create a repository. OdTfRevisionControl allows you to create an empty repository (an empty .dwg database in the repository is created). You can also import an existing .dwg file into the repository.
OdTfRevisionControl works in single-user (local) mode, but it also has an API that allows you to work in multi-user mode (client-server). The makePatch / applyPatch functionality is the part of the OdTfRevisionControl API that can be used for client-server mode.
There are various workflows for version control systems. Many of them describe work with different branches. With the help of OdTfRevisionControl you can create a new branch for work, as well as merge it with another.
Compression of revision data
If you change only one object in a drawing, the object itself will be placed in the commit along with the objects that were dependent on it that also changed. So, if you make a "move / drag" for all objects, the commit will be large. To reduce the volume of the repository (reduce the size of the commit), there is a compressRevisionData function in the OdTfRevisionControl API. With each commit we do not automatically compress objects, but with the help of the API, you can compress N commits at once.
When moving between commits (to get the desired commit), the compressed data must be restored to its previous form, which takes time. To restore compressed data, you need a reference point (the initial data, in relation to the previous data that was compressed). To reduce the time for recovery, the initial state (the whole) should be as close as possible to the compressed state. For this, compressRevisionData compresses objects in commits at a specified interval. In other words, when the specified depth of compression is reached, the object will not be compressed but will be compressed in the future.
Below you can see an initial state of a drawing and changes for each commit.
The table below shows the size of the repository in the initial state, the size after each commit, and the size after the compression of all commits. In this example, operations were performed to move and delete objects.
| Size (Kilobytes) | The difference in size | |
| The source repository size | 8,564 | |
| Commit 1 | 8,840 | +0,276 |
| Commit 2 | 8,884 | +0,44 |
| Commit 3 | 8,928 | +0,44 |
| Commit 4 | 8,972 | +0,44 |
| Compressed | 8,756 | -0.216 |
Below you can see another example of an initial state of a drawing and changes for each commit.
The table below shows the size of the repository in the initial state, the size after each commit, and the size after compression of all commits. In this example, all of the drawn objects were moved, selected objects were moved, and new ones were added.
| Size (Kilobytes) | The difference in size | |
| The source repository size | 10,052 | |
| Commit 1 | 11,068 | +1,016 |
| Commit 2 | 12,072 | +1,004 |
| Commit 3 | 13,916 | +1,844 |
| Compressed | 10,052 | -3.864 |
Conclusion
Initially version control was available only for files in text form, and the specificity of the .dwg file format did not allow for easy version control. Now, using OdTfRevisionControl is a powerful tool when working with a drawing both individually and for a team of developers.