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

Hoe does IW Store Versions?

mankev

Does anyone know how Team Site stores it's versions?
Does it store a differential or full version of the file.
Are the stored files compressed?

Thanks
km

Find more posts tagged with

Comments

JonathonG

Full versions are stored, and I don't believe any compression is done.

Jonathon
Interwoven Developer
Allstate, Inc.

mankev

Thanks
I better watch those hoes.
km

DJ_At_Work

interesting response. never thought of teamsite's backing store as 'hoes' before.

:-)

gzevin

As you know, there are 2 types of versioning. STAGING has full versions stored, whereas editions are deltas.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

As you know, there are 2 types of versioning. STAGING has full versions stored, whereas editions are deltas.

I think that's a somewhat misleading statement.

Staging only presents a single version of each active asset - it does not provide versions.
Editions are essentially reference pointers to specific versions of assets in the backing store that existed in staging at the point in time when the edition was created.
It is the existance of an area (staging, workarea, or edition) containing at least one reference to a version of a file that keeps that specific version of the file from being "garbage-collected"
All versions of files in the backing store are complete versions - not deltas (as exist in such version management systems like SCCS, RCS and the many derivitives thereof)

I can't remember when they got rid of it (5.5.2 or 6.x) - but there used to be an option for "compressing editions". It turned out that it really didn't save that much space (because you were really only compressing a list of reference pointers I believe) and that it was lousy for performance - so that "feature" went away.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

gzevin

Let me disagree with you. Not on technical issues, but on terminology.

Staging only presents a single version of each active asset - it does not provide versions.

Yes it does not provide a number versions. But the versions of individual files that have been submitted from workareas do exists, and they ARE kept as full versions. And for a user one can safely say that there ARE full versions of individual files stored.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

I guess we're on semantics here - I consider the staging area to be a "view" of the most recently submitted version of each file. To obtain alternate versions one goes through editions and/or restoring into a workarea from a history list. I read the statement " STAGING has full versions stored" as an indication that the pool of historical versions for each file was in staging - which is not correct - they may be accessible by viewing the history of the file while in staging, but that's not quite the same thing.

However, my main point was not regarding the staging area - but with regard to " whereas editions are deltas" - which makes it sound like editions store deltas of versions of files - which is not the case. They store references to versions of files at a particular point in time, and it is possible to easily create a list of changes (deltas if you wish) between any two editions by comparing the items to which the references point.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

gzevin

Adam,

I value your elaborative style, but please agree that I did say pretty much the same - that there are full versions of individual files, that are stored in the backing store, and if I may say so, for a user, *look* like they are in staging. Also, with the editions - they are, from my point of view, deltas, as they could be easily made ones. Smiley Happy

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

I did say pretty much the same - that there are full versions of individual files, that are stored in the backing store, and if I may say so, for a user, *look* like they are in staging.

Agreed.

Also, with the editions - they are, from my point of view, deltas, as they could be easily made ones

I'm not sure I agree - but it isn't worth arguing too much about. My reasons for concern about the statement have already been made.

Have a happy halloween ;-)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

TopTenSample.rptdesign

gzevin

Thanks

It's your pagan holiday Smiley Happy

They are trying to make it a similar stuff in OZ, but with a very little success... Maybe some teenages are having acid parties

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Johnny

In reply to:

It is the existence of an area (staging, work area, or edition) containing at least one reference to a version of a file that keeps that specific version of the file from being "garbage-collected"

Is this really the case - as that means it's possible to remove a certain part (or all) of file history.
I understand there is a reference for every file submitted as each submission creates a hidden edition. If you delete a published edition - all of the file history between that edition and the previous edition (all of the hidden editions) will be removed.

Sounds fair in terms of controlling disk space - but it also sounds quite dangerous in terms of inadvertently removing history that may be required from a legal stand point. Seems like everyone should be quite aware of that implication.

John Cuiuli

Adam Stoller

To be perfectly honest - I've never verified the garbage collection semantics of TeamSite because I don't think any of my customers had ever implemented a procedure for removing "old" data or similar. My statement is based on what I recall from talking to IWOV Engineers while I was still employed by IWOV and so I *believe* it to be true. Testing it would be a reasonable step - but even then, just because something is "available" for garbage collection, doesn't mean it is automatically removed.

I think Smitty probably had the most direct involvement with this kind of thing, where he put together a process for removing old editions at Nike and was able to see their backing store size hit a kind of plateau which indicated that it was working as expected/suspected.

Continuing from a theoretical standpoint - if there are no areas referencing a particular version then it would seem that version has little value and its removal should not present much of a problem. Since all versions are stored in their entirety (not deltas) the removal of any intermediary version does not affect the ability to retrieve versions of the file before or after that particular instance.

If my undertstanding of the procedure is correct - if you have something like:

INITIAL, #1, #2, #3, ED1, #5, #6, #7, ED2, #9, #10, ED3, ED4, #13, #14, ED5

And you remove ED2, then versions #5 through #8 (synonymous with ED2) are available for garbage collection, while #9 & #10 are not; leaving you with:

INITIAL, #1, #2, #3, ED1, #9, #10, ED3, ED4, #13, #14, ED5

Heather/Lisa - it would actually be nice to get an IWOV Server Engineer to validated / correct this information here in the forums ...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

smenon

OK.. Let me take a stab at explaining this.. I will have to explain some of the inner workings, but hopefully it will be clear at the end of the description.

Every time you submit a file, TeamSite creates a new version of that file. TeamSite also creates a hidden edition that essentially is a snap-shot of that file version in relationship to all the other current (latest) versions of other files in that branch. When you create an EDITION in TeamSite you are essentially creating this snapshot of all files in an area (STAGING) and providing a "label" to that snapshot.

As you submit newer versions of files, TeamSite stores the entire file contents as older versions and this is not based on a delta. Creating EDITIONS does not indicate that additional copies of files are created. If a file version has not changed (indicating that a file has not been submitted in between two editions), both EDITIONS will essentially point to the same file version in the backing store. As ghoti pointed out, EDITIONS are a collection of virtual pointers to file versions in the backing store, but semantically they are also virtual containers of all the assets that make up the sanpshot.

Now when it comes to garbage collection, there is no automatic garbage collection. Deletions of file versions are triggered by deletes of higher-level containers (such as EDITIONS or WORKAREAS or directories). When you delete an EDITION, all the file versions contained in that EDITION will also be deleted - as long as the files (the version contained in that EDITION) are not being used anywhere else (for example : in a workarea or in other EDITIONS). Additionally, all intermediate versions between this named EDITION and the last named EDITION will also be deleted if not being used elsewhere.

Example : Version 2 of file "foo.txt" is contained in edition ED_01. You have since modified foo.txt 3 times creating version 5 of foo.txt which has been submitted to STAGING. Publish an EDITION called ED_02. You have modified foo.txt twice since then and it is currently at version 7 both in STAGING and in your workarea - wa1.

You now create a new workarea (wa2) and using the version history of foo.txt, you update your workarea to contain version 4 of foo.txt. (Note : you have not modified the file yet, but the workarea just contains version 4 of foo.txt).

At this point, version 3 of foo.txt is not part of any named EDITION or is not in any workarea (and so the reference count is 0). Version 4 has one reference - wa2 and version 5 has one reference - ED_02.

If you try and delete ED_02, TeamSite will delete version 5 as soon as it deletes the ED_02. It also deletes all hidden editions (and subsequently file versions) in between the two named EDITIONS ED_02 and ED_01. Hence, after deleting version 5 of foo.txt, it then tries to delete versions 4 and 3. Version 4 cannot be deleted because it is still being used in wa2 (and reference count is not 0). Version 3 however, is deleted because it is not part of any EDITION and it is not being used anywhere.

Now, at a later time, if you delete wa2 without modifying foo.tx (version 4), as part of that delete operation, it will also delete version 4 of foo.txt because it had no other references to it and its reference count will now be 0.

I hope this makes sense.

thanks

--Sunil Menon
Sr. Product Manager
Interwoven, Inc.

jbonifaci

Thanks for clearing things up Sunil, these guys could have gone on for days,

.

~Jeff

kinsting

I have a related problem (and forgive me if my introducing it here is disruptive) having to do with the viewing of previous versions of any given DCR/file.

My problem is that since in our applications we do not use the EDITIONS feature, we are finding that we cannot (at least through the TeamSite UI) view/preview versions of our DCRs. We can bring up the Versions page corresponding to a DCR (via DCR 'Properties' link and from there the 'Versions' link). From this versions page, we can select a specific version and hit the 'Preview' link. So far, so good.

However, what we are seeing at this point is a "form rendering" of the DCR. If we want a "real" preview (that is, an HTML rendering) and attempt to get that by hitting the 'Preview' link (upper-right corner of the "form rendering" page), what we see is the error:

"Preview and Generate Preview and Generate:
The following error occurred while creating file /opt/.iwmnt/default/main/AppleCare/Active/EDITION/#7656/templatedata/zz_tst_kinsting_lock:
No such file or directory.
The file was not generated."

From reading this thread, it seems that the versions are at least there in the content store. My problem is getting them out in a rendered format. Any suggestions? Thanks.

Jon Kinsting
jkinsting@apple.com

nipper

You should start a new thread for this

However one thing I noticed:

/opt/.iwmnt/default/main/AppleCare/Active/EDITION/#7656/templatedata/zz_tst_kinsting_lock

Is iwmnt really under /opt ?

What OS (Linux I assume) ? What rev of TS ?

run this command on the server

df -k

& post the results.

Johnny

You can preview a DCR unless it's in your workarea, because it attempts to write files in the area you are in. Earlier versions of files are either in a hidden or named edition which is readonly.

You'll have to revert that file to your workarea if you need to preview it, the other option is to view the generated file if it exists in that area.

John Cuiuli