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

Deleting edition deletes versions of files - why?

B80116

I have made the unpleasant discovery (unpleasant to me, at least) that deleting an edition deletes all versions of the files that are contained
within that edition.

What is the rationale for doing this?

I want to delete an edition, but I don't want to lose the ability to revert to previous versions of files that are in that edition. It appears that I do, however.

Find more posts tagged with

Comments

iwovGraduate

deleting an edition deletes all versions of the files that are contained within that edition.

I thought deleting edition would delete versions of files that are unique to that edition.

I wonder whats your rationale behind deleting editions then ?

B80116

I'm getting my information from the TeamSite WebDesk Pro User’s Guide Release 6.0, page 94:

"The workarea, branch, or edition is deleted, together with all its contents. Deleting a
branch deletes all editions, workareas, and subordinate branches contained in that branch.
In addition, deleting a branch or edition deletes all versions of a file that are contained
within that branch or edition."

I'm writing a workflow to publish an edition, then deploy from that edition to our various servers (QA server, Staging server, Production servers). There is often a delay of several days between the deployments to the various servers, as various groups in our company have to buy off. Cutting an edition and then deploying from that same edition seemed like a perfect way to ensure that the same file versions went to each server. Once the files are deployed from the edition to the Production servers, I had intended to have the workflow delete the edition, as we no longer need it, and editions are going to build up rapidly if we don't delete them.

However, it appears that the act of deleting the editions destroys the ability of our developers to roll back or refer to earlier versions of their work, as these versions vanish from Staging when editions are deleted.

Dwayne

I could be in error here, but my understanding is that deleting the edition does not automatically delete the version. It merely decrements the reference count to that version. If the reference count reaches zero, then the version is eligible for garbage collection. Thus, the only time you are in any danger of losing a file version is if that edition is the ONLY location where that file version is referenced. Which is less likely than you might think, given the way that "hidden" editions are created.

But I think you're whole premise is flawed. Why bother deleting the editions at all? Since it doesn't sound like you plan on allowing users to navigate through old editions (you do plan on deleting them, after all), the large number of editions shouldn't matter. Performance and disk usage should be impacted very little by having a lot of editions - it's only in the UI, navigating through a large number of editions that I've seen some usability issues.

--

Current project: TS 5.5.2/6.1 W2K

B80116

"Since it doesn't sound like you plan on allowing users to navigate through old editions (you do plan on deleting them, after all), the large number of editions shouldn't matter. Performance and disk usage should be impacted very little by having a lot of editions..."

That's good to know. My primary motivation for deleting the old editions was simply to be tidy!

Dwayne

Older version of TS DID have a problem with large numbers of editions, and the reommendation was to delete old ones. However, with the new backing store format, hidden editions are created every time you perform a "submit" operation, so the system HAS to be able to handle a large number of editions gracefully.

--

Current project: TS 5.5.2/6.1 W2K