Using Design History

Hi

I think about using design history but are afraid the files will increase much in size. Is there a number on how much they grow with/without design history initiated? 

Second. Having to initiate design history in every file within my workset is not very smooth. When you're at the beginning of a project it's easy to remember på initiate, but if you create a new file halfway, the user will probably not remember the initiate this. There should be a configuration variable to put in the workset .cfg-file or something like that. Maybe divided so I can use it only for design/drawing/sheet-models.

Is it also required to store the design history in the dgn-file itself? At our office, awhile after the project is finished our IT-contractor will compress all files and store them at the archive-server. They will not have the ability to open all files and delete the design history, but if the history were to be saved in a separate file, they could just delete that file while archiving the project to minimize the size of the project. 

Last. One of our main reasons for using design history is to be able to see who created/modified an element last. But that's not very easy to do anyway. You can't select an element to see who created it, you have to find the last revision that affected that element, and see how was the author of that. I find a tool for this would be very useful, keeping track of users.  

Regards, 

Robert

Parents
  • Hi Robert,

    I have no experience with using Design History in building products, so just a few notes based on MicroStation experience:

    Is there a number on how much they grow with/without design history initiated? 

    As far as I know there is no such number available and in fact it cannot be determined in my opinion. How the files will grow in size depends on a number of changes and also their type. When you wil delete thousand of elements and will create another thousands, everything has to be recorded, so the increase will be bigger than when you modify just a few elements. The Design History itself (administration of the history records) has very small size footprint.

    When you're at the beginning of a project it's easy to remember på initiate

    I guess you can initiate the design history in seed file, so it will be active when the new file is created.

    There should be a configuration variable to put in the workset .cfg-file or something like that.

    "Should be"? ;-) ... what does it mean? If you have a request for the new feature, put it into MicroStation Ideas section.

    Maybe divided so I can use it only for design/drawing/sheet-models.

    Design history is "all or nothing", you cannot activate it only for some models in a design file.

    Is it also required to store the design history in the dgn-file itself?

    Yes, the history records are integral part of DGN file and data integrity is maintained. It cannot be split to another "storage".

    At our office, awhile after the project is finished our IT-contractor will compress all files and store them at the archive-server. They will not have the ability to open all files and delete the design history

    It's possible to retire a part of thi history or to keep the current state only. I assume it can be done in batch processs also.

    but if the history were to be saved in a separate file, they could just delete that file while archiving the project to minimize the size of the project.

    How you can maintain history integrity when source data and history will be separated? What will happen when e.g. history file will be not available when the file will be opened and modified?

    One of our main reasons for using design history is to be able to see who created/modified an element last.

    It's not how Design History works, its philosophy is different and close to e.g. code versioning systems (like e.g. Git), where a commiter who creates the revision, takes an ownership of all changes. It means Design History does not store explicitely who changed what element.

    But that's not very easy to do anyway.

    Well, despite of it's not Design History primary functionality, it can be configured quite close to it: Using configuration variables you can define a commit will be done when the file is e.g. saved, closed or model switched, so when a user starts MicroStation, does some changes and will close the file, it will be asked to store the revision, so it will be recorded that this use saved this revision, consequently he did the recorded changes.

    With regards,

      Jan

Reply
  • Hi Robert,

    I have no experience with using Design History in building products, so just a few notes based on MicroStation experience:

    Is there a number on how much they grow with/without design history initiated? 

    As far as I know there is no such number available and in fact it cannot be determined in my opinion. How the files will grow in size depends on a number of changes and also their type. When you wil delete thousand of elements and will create another thousands, everything has to be recorded, so the increase will be bigger than when you modify just a few elements. The Design History itself (administration of the history records) has very small size footprint.

    When you're at the beginning of a project it's easy to remember på initiate

    I guess you can initiate the design history in seed file, so it will be active when the new file is created.

    There should be a configuration variable to put in the workset .cfg-file or something like that.

    "Should be"? ;-) ... what does it mean? If you have a request for the new feature, put it into MicroStation Ideas section.

    Maybe divided so I can use it only for design/drawing/sheet-models.

    Design history is "all or nothing", you cannot activate it only for some models in a design file.

    Is it also required to store the design history in the dgn-file itself?

    Yes, the history records are integral part of DGN file and data integrity is maintained. It cannot be split to another "storage".

    At our office, awhile after the project is finished our IT-contractor will compress all files and store them at the archive-server. They will not have the ability to open all files and delete the design history

    It's possible to retire a part of thi history or to keep the current state only. I assume it can be done in batch processs also.

    but if the history were to be saved in a separate file, they could just delete that file while archiving the project to minimize the size of the project.

    How you can maintain history integrity when source data and history will be separated? What will happen when e.g. history file will be not available when the file will be opened and modified?

    One of our main reasons for using design history is to be able to see who created/modified an element last.

    It's not how Design History works, its philosophy is different and close to e.g. code versioning systems (like e.g. Git), where a commiter who creates the revision, takes an ownership of all changes. It means Design History does not store explicitely who changed what element.

    But that's not very easy to do anyway.

    Well, despite of it's not Design History primary functionality, it can be configured quite close to it: Using configuration variables you can define a commit will be done when the file is e.g. saved, closed or model switched, so when a user starts MicroStation, does some changes and will close the file, it will be asked to store the revision, so it will be recorded that this use saved this revision, consequently he did the recorded changes.

    With regards,

      Jan

Children
  • As far as I know there is no such number available and in fact it cannot be determined in my opinion.

    Maybe someone who uses... DH have an approx number for real projects. It's not very often you delete 1000 elements. But I get your point. 

    "Should be"? ;-) ... what does it mean? If you have a request for the new feature, put it into MicroStation Ideas section.

    Yes, maybe I should! 

    Design history is "all or nothing", you cannot activate it only for some models in a design file.

    We always have one model per file, so it would make sense to only use the DH on the files containing the design models. But sure, I guess the drawing files are very small in size compared to the design files. 

    How you can maintain history integrity when source data and history will be separated? What will happen when e.g. history file will be not available when the file will be opened and modified?

    My idea is to have as you mention further down the configuration variables set to commit a change every time the users close a file. So if a crash occurs, and the user don't open the same file after the crash, another user would take charge of the change. I guess the same thing could work if there was a backup file in the worksets folder somewhere, and it's not available to write to for some reason. I'm not a programmer, so I don't know, but it don't look to hard to fix? 

    It's not how Design History works, its philosophy is different and close to e.g. code versioning systems (like e.g. Git), where a commiter who creates the revision, takes an ownership of all changes. It means Design History does not store explicitely who changed what element.

    But as you say it can be sort of done, and that's what I have in mind. Although the functionality of tracking the author of every element in a file feels like something almost every MicroStation user could benefit from, not just OBD-users (or how far DH is spread), or I'm I wrong? 

  • So if a crash occurs, and the user don't open the same file after the crash, another user would take charge of the change.

    When a crash occurs, it's hard to say what will happen. It's exceptional situation that cannot be solved by the same applicaiton (technology), but has to be addressed by another application or a process.

    Because changes are saved automatically to DGN i short transactions, I guess the crash result will be as you described: There will be not commited changes. In such case a new user is informed whether he want to take over the changes or he wants to close the file. It's more about processes again, and e.g. when ProjectWise is used, it's easy to find who checked out the file and to request this user to fix the issue.

    I'm not a programmer, so I don't know, but it don't look to hard to fix? 

    No, it's not possible from many reasons. It's not simple (I guess not possible at all) to design any robust system in such way, especially when the format (DGN) is defined. It can be demonstrated on databases, where everything is done in transactions and DB files have high redundancy to ensure they can be recovered, and when files are split because of performance reasons, the whole system internally become pretty complicated.

    And in fact, there is nothing to "fixed" (in terms of solving bug), because DH works exactly as was designed. Such discussion is about changing of DH concept, which can be valuable, but will be not treated as bug fixing.

    Although the functionality of tracking the author of every element in a file feels like something almost every MicroStation user could benefit from, not just OBD-users (or how far DH is spread), or I'm I wrong? 

    I disagree, because I think I heard such request maybe once or twice in last 15 years? There are both technical issues (DGN format is not designed to be optimized for such granularity) and performance penalty (to maintain records for every change is not simple quick task). And as for any development: It's all about balancing between complexity (to design system, implement, test, maintain) and real benefits.

    BTW If you are interested in "changes monitoring", not to be able to return back in history, only to see who changes elements (and e.g. to record it to some external database), I guess it's possible to develop such monitoring application. But to make it useful and simple to use will be challenging, because what a user see as one change, can be represented by tens of changes internally (XAtttributes attached to element, maintaining relationships and dependencies), so to find a right granularity would require some testing and code evolution.

    With regards,

      Jan