Teamsite version administratio in 6.7.1

chicka

Hi All,

This may be a basic query to the experts, but I having many approaches for my query. Basically I believe this thread may help to get a defined approach with your help.

I am running my content store in TS6.7.1 on Solaris box and we had a major problem in disk space. So we went for iwfsshrink utility during off working hours and it helped us to save lot of space and we have made a thumb rule to use this utility once in a quater.
Now we have a requirement wherin we are forced to maintain only 10 latest version for a file(DCR as well as asset). My intial thought on the solution is to go for EDITION. But what I feel is, this may not serve my client purpose as all the files in an WA is not touched simultaneously. (I may be wrong )
My query is how to maintain constantly 10 latest version for all the files in my content store.

Please shed light on this.

Adam Stoller

&t

Hi All, This may be a basic query to the experts, but I having many approaches for my query. Basically I believe this thread may help to get a defined approach with your help. I am running my content store in TS6.7.1 on Solaris box and we had a major problem in disk space. So we went for iwfsshrink utility during off working hours and it helped us to save lot of space and we have made a thumb rule to use this utility once in a quater. Now we have a requirement wherin we are forced to maintain only 10 latest version for a file(DCR as well as asset). My intial thought on the solution is to go for EDITION. But what I feel is, this may not serve my client purpose as all the files in an WA is not touched simultaneously. (I may be wrong ) My query is how to maintain constantly 10 latest version for all the files in my content store. Please shed light on this.

Well - your first hunch and caveat are correct - editions are the way to go, but that won't limit each file to 10 versions.

TeamSite does not provide a mechanism for deleting specific revisions of specific files. If you maintain 10 to 20 editions per branch, you are likely to maintain between 10 and 20 revisions of files that change frequently, but also likely to retain less than 10 revisions of files that change infrequently.

E.g.: (assume latest revision is same as staging)

Edition	file	rev	file	rev	file	rev	file	rev
ed_0001	foo.html	1	bar.html	1	baz.jpg	1	mumble.html	1
ed_0002	foo.html	2	bar.html	1	baz.jpg	1	mumble.html	5
ed_0003	foo.html	3	bar.html	1	baz.jpg	1	mumble.html	10
ed_0004	foo.html	4	bar.html	2	baz.jpg	1	mumble.html	15
ed_0005	foo.html	5	bar.html	2	baz.jpg	1	mumble.html	20
ed_0006	foo.html	6	bar.html	2	baz.jpg	1	mumble.html	25
ed_0007	foo.html	7	bar.html	3	baz.jpg	1	mumble.html	30
ed_0008	foo.html	8	bar.html	3	baz.jpg	1	mumble.html	35
ed_0009	foo.html	9	bar.html	3	baz.jpg	1	mumble.html	40
ed_0010	foo.html	10	bar.html	4	baz.jpg	2	mumble.html	45
ed_0011	foo.html	11	bar.html	4	baz.jpg	2	mumble.html	50

If you delete ed_0001 after creating ed_0011, revision 1 of foo.html becomes subject for removal from the backing store. Assuming a consistent change frequency, you will be deleting an old revision of foo.html everytime you cut a new edition and thus maintaining ten revisions of that file.
However, when you delete ed_0014, ed_0017, and ed_0020 you will also be allowing for revisions 1, 2, and 3 (respectively) of bar.html to get removed from the backing store, thus maintaining a maximum of four revisions of bar.html at any one time; and when you finally reach ed_0021 and delete ed_0010, you will be allowing revision 1 of baz.jpg to get removed from the backing store, thus maintining a maximum of only two revisions of that file.
On the other side of the coin, mumble.html changes frequently between (named) editions, thus when you delete ed_0001 after creating ed_0011, you are actually allowing for the removal of revisions 1 through 4 of mumble.html from the backing store thus maintaining between forty-five and forty-nine revisions of that file. (I might have a 1-off or so in the above, but hopefully you get the picture)