I am working on a database management application and I store the database objects (Tables, views, triggers, etc...) in a tree and I need some extra insight in re-thinking the features of the tree regarding to some new feature I have started to implement.
The philosophy of the application is to have a "Solution", this Solution contains more "Projects", the Project contains a "Major version", and all the database objects (such as listed above) are the children of the "Major Version" tree node.
In reality this looks like:
So, as you can see the tree below the version contains a little bit more than just the tables, views, etc, since the application allows you to create also diagrams with the database objects, generates SQL code and documentation too...
Now, comes the dilemma:
I have started to implement versioning support for the application, this in fact means that after the Release of "Ver: 1.0" there will be another tree entry below this, named "Ver: 2.0" which will basically have the same elements as you see right now which totally makes sense, since the user will need to start from V1.0. (However after a release, all the objects in V1.0 will be "locked" and the user will need to specifically unlock them if he wants to work on them (thus resulting version 1.1))
But I have a concern related to the positioning of non-database elements in the tree (Diagrams, Documentation, Code) since versioning for them makes no sense.
I basically have to approaches in my mind to attack this:
reorganize the tree, in a way that I "pull up" these elements one level, so that they are at the level of "Ver: 1.0" bu this might cause another issue, since the diagrams (for example) are created with the elements found in the version they are placed, and so is the code generated based on the elements of the version, so pulling them up might cause confusion.
leave the tree as it is
what do you think would be the best approach for this?