nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Actual size of teamsite edition?

Crsb

I know the edition size depends on the number of changes compared to the edition before, i am not sure if there is an easy way to get the actual disk space an edition is taking.

Is there away to get or calculate/estimate the actual size of an edition?

Find more posts tagged with

Comments

nipper

Of a specific edition, you could check the differences from the previous edition and calculate it.

Adam Stoller

I know the edition size depends on the number of changes compared to the edition before, i am not sure if there is an easy way to get the actual disk space an edition is taking.

Is there away to get or calculate/estimate the actual size of an edition?

Often when someone asks a question like this, it's because the fundamentals of TS are not well understood.

Accuracy is in the eye of the believer - if you believe that each edition contains data the comprises the actual content differences between one another they, as Nipper indicated, you could come up with a form of calculation. If, however, you believe that each edition is simply a manifest of references to versions of files (and not the actual files themselves) then the means of calculating the disk space used solely by the files referenced from that edition can be a bit more complex.

Consider that a given version of a file can exist within multiple editions (and staging, and workareas - but we'll ignore those for now) - as such, you cannot really ascribe the space utilized by that version of that file to any single edition (i.e.: If you delete that edition it will not free up the disk space associated with that version of the file). If you create 10 editions in a row without making any changes to the versions of the files - the size of the edition is simply the size of N file version reference pointers (and metadata references)

So - you'd probably first have to filter the list of versions of files associated with the edition of interest with the list of versions of files for the editions just prior to, and just after (if any) to get a list of unique versions of files. If there is no newer edition, you'd have to compare it with the list of versions of files in the staging area and potentially with each workarea on that branch as well.

Once you have a list of versions of files that are unique to the specific edition - you can then add together their file sizes and that should give you an approximate size of all the files uniquely associated with that edition (in this case, if you were to delete that edition you might reclaim that amount of space)

Perhaps the big question is: Why are you trying to get this information? What are you hoping to do with it?

Crsb

....
Once you have a list of versions of files that are unique to the specific edition - you can then add together their file sizes and that should give you an approximate size of all the files uniquely associated with that edition (in this case, if you were to delete that edition you might reclaim that amount of space)
Perhaps the big question is: Why are you trying to get this information? What are you hoping to do with it?

so the short answer is to not even bother lol...

I am trying to make a projection of disk space usage for next year. so i thought to consider the number of submits/editions since we do make large number of submits everyday.

ISCBorisB

so the short answer is to not even bother lol...

I am trying to make a projection of disk space usage for next year. so i thought to consider the number of submits/editions since we do make large number of submits everyday.

Firstly, you may look at STAGING as a single anonymous Edition, so the number of Submits is irrelevant. What matters is
the number of modified Files and how often do you Publish Editions (eg, create History references)

Secondly, 2 to 8K is a reasonable estimate of the B-tree Node Size, depending on the maximum number of children.
So, consider average 5K to be the TS internal reference size - in case you do not have any better information (it's probably w-a-a-y
more than IWOV is really using). Estimate publishing frequency, total number of Edition's Files, average File Size and percentile
of modified Files per Edition and you can start calculating.

Alternatively, you may consider that "One Tera" Disk costs around $200 nowadays and that all of the above gobbledegook is good
for perhaps impressing some procurement Manager and very little else. See what amount of Data you currently have, estimate
versioning and growth and multiply by five - chances are you'll have as good or better Space requirements than with any pseudo
scientific calculations