I have some massive warehoused cubes, and they have loads of revisions as I have checked them in and out many times over the past years.
Is there any way to clear out older revisions to free up some disk space on the server? Or do these versions not take up space?
Thanks
I been getting in the habit if I only need to look at it to check it out then undue checkout instead of checking it back in when there been no change.
This is a very interesting question on how they store the previous versions, I Assumed it was a database entry and was there for light weight.
I just so happened to clean out my dev server and reload it with a fresh copy of prod, when I do that I do not bring over all revisions ( If i do it makes the export file huge and takes forever to make and import). I do not need the history for dev so I just leave it off on the export.
Also interested in the answer to this question.
If you donât care about the revisions at all, check in the content and them publish it somewhere or duplicate it. I believe publish will be the equivalent of making a ânew versionâ. Then you can delete the old content, removing the old revision history.
This does sound rather tedious to do.
Is there an easier way to do this? Or a setting to only keep âxâ previous versions?
How much space does each version actually take up? What determines the size, and where can I check the actual size?
Thanks
Agreed but itâs probably a lot less tedious than creating 1K check-ins though⌠
We could open a feature request for this but iâm a bit concerned that itâs contradictory to the whole point of source control where nothing is ever deleted. There might be some push back on such a request.
It shouldnât be too large as itâs compressed XML, are you having issues with the size of your application? Maybe time to run the healthcheck?
https://www.dundas.com/support/learning/documentation/administration/health-check
Publishing does sound tedious, and what if you have Dev projects that you Publish to Prod projects? you loose the link at that point dont you?
Well in that case you could just change the Prods to devs and make new prods but that is even more tedious to change all and set up all the permissions, especially if you have special permissions in some prod projects on sub folders.
Yes that idea would be a nightmare.
I can see it sparking some debate, but there is definitely an argument not to keep stuff that you will never ever go back to. Iâm sure many will agree.
I have done all the healthchecks and itâs all ok. We are trying to free up a load of disk space on the server, so would be interested in knowing which database / file this info is stored in, and if the size of the cube affects it.
I agree, maybe if you add in the ability to mark a revision as a Production ready version.
I say this because for me anyway I check in something I am trying and then make fix check in until I get it right. I do not need all those nor would I want to go back to those revisions that are trail test and not working.
Also after I got it working, I can see that I might want to go back to the last working version , but I have to rely on memory and dates to figure out when I started fiddling with it and what revision was the working one.
The ability to just keep last 3(variable) working revisions not this was just a step to the working one would be nice.
Great points as usual guys. Iâll create a Feature Request and document everything you are saying.
By the way. There is an option on advanced options page in Export to include all revisions. It is off by default. So if a DBIE was exported without revisions, it would not have them on import. So it depends on your preference when working from Development to Production.
I know, i never check it, unless I am using that as a back up for all my projects. (I usually just back up the database for that).
We still would like to know where the files are and see how big they are.
Did some digging and there is an API that will allow you to clear old revisions. Do back up your application database before playing with this but it should help for now.
Also, the DT.EXE tool has a function for deleting Old Entity Data.
Just thought I should probably be using the check in comments for this but I do not know if this fix totally fixes everything when I am checking it in, so I need to be able to set it after check in.
Thanks Jeff - Iâve had a go with the dt tool and deleted revisions from before 2019.
This deleted 37,262 revisions - surely that must be a decent chunk of disk space even with all the compression.
Can you still continue digging into how I can see how much storage is actually used for these, please?
@david.glickman - although 30k records may have been deleted from the DB after running dt.exe, this doesnât necessarily mean that disk space will be instantly reclaimed. For instance, with SQL Server, the database typically needs to be manually âshrunkâ - that is, unused space in the on-disk database file gets released, meaning the database will then consume less space on the disk. If youâre using SQL Server for your app DB, you can shrink the DB using SSMS.
Regards,
Rob.
Also - if you want to see whatâs taking up so much space in the App DB, you can run the âDisk Usage by Top Tablesâ report from SSMS.