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; } } }

Editions

rpjoseph

We are new to Teamsite. We are using 5.5.2.

What is the best practice for creating editions? Specifically - How often do you all create editions?

I was considering as part of an automated nightly housekeeping process to clean log files, etc to create a new edition. Is that too many?

I saw another post that said there is performance degradation after 500 editions. Can editions be archived? So - if we created a new one every night we could check to see if there were any editions over 6 months old or something and write the editions to a file system to eventually be placed on CD or something????? (ooops babbled out loud again)

Thank you for your help

Find more posts tagged with

Comments

james1

> I saw another post that said there is performance
> degradation after 500 editions.

This only applies to versions of TeamSite prior to 5.5.2.

> Can editions be archived? So - if we created a new one
> every night we could check to see if there were any
> editions over 6 months old or something and write the
> editions to a file system to eventually be placed on CD or
> something????? (ooops babbled out loud again)

This would probably use a tremendous amount of space, especially if you're publishing editions at least once a day.

-- James

--
James H Koh
Interwoven Engineering

Adam Stoller

In case it wasn't clear from James' post the "tremendous amount of space" would be with regard to the archiving of editions *outside* of TeamSite.

Within TeamSite editions are essentially pointers to specific versions of files - if you go through the file system and copy the contents of an edition to someplace outside of TeamSite - those references all become actual files - and thus you will be paying for storing a considerable amount of identical data when copying editions out to removable media like that.

One potential solution I like is the idea of using specifically named editions (monthly, quarterly, or something like tha) in conjunction with TeamSite MultiStore via the iwmigrate utility. In this way you could replicate portions of the backing store into a separate store and then dump that to a CD or something. You'd preserve historical data and metadata and be able to re-introduce the data into TeamSite at a later date if you needed to.

Please note: MultiStore is an additional license cost - consult your Interwoven Sales representative for more details.

--fish
(Interwoven Senior Technical Consultant)

project_folder.PNG

msrich

As a follow-on to IWMigrating an edition to its own backing store, would you see deleting that edition from the original store as viable? Would such a deletion adversely impact performance on the server?

The best practice we've followed in the past is to have users leave behind their branch and begin work in a new one when the original contains too many editions (over 500 or so).

With MultiStore, IWMigrate, and CD-archiving of editons, maybe it's time to think about purging some editions in the original branch and allowing users to remain there.

Comments appreciated. Thanks.

Adam Stoller

As of 5.5.2 - deleting editions no longer imposes the kind of dreadful performance overhead that previous versions of TeamSite incurred. I think that transferring (removing them from the old store, putting them into the new store) editions to a separate store (provided you've licensed MultiStore), archiving them on something like a CDROM or DVDROM, and then taking the "archive" store off-line is a reasonable approach.

However, I should say that the above is theortical in that I have *not* performed this kind of archival/retrieval process anywhere (I've thought about it a number of times, but never actually implemented it).

You might be able to leverage the kind of script that Smitty developed for deleting editions to instead migrate them for archive.

Of course, the other question is: Do you really need to preserve the data that's "so old'? and that's something only you can answer based on your organization's requirements.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

This situation is not exactly the same as what you are looking for, but people reading this post might be able to benefit from this option as well.

In IWOV engineering they had a store that was started with TeamSite 1.0. It had years over editions and old branches. When the system up upgraded to 5.5.2, the team left the ancient data in the old store, and kept the 5.0.2 version of TS around for the old data.

They migrated the newer data into multiple stores, leaving room for future growth.

You might be able to apply a similar process to a 5.5.2 system, by moving some data to a newer store, and leaving the older one as an 'archive'.

Regards

lissa