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

Directory based and TeamSite based comparison

cliffhanger

Hi,
This is not a technical issue, rather a conceptual problem. Anybody any thought, I would appreciate it.

What's the difference between directory based and teamSite based comparison in deployment? In both methods, directories( any directory or teamsite workarea,edition) are compared between source and target hosts and the differences are deployed to the target. Then how come the TeamSite documentation says "directory based comparison can put a high demand on time and network bandwidth resources because all file and directory information must be exchanged over the network to determine file differences" whereas it says "This method is faster and requires less bandwidth than the directory comparison because it takes place on the TeamSite source host; No network traffic is generated before the file deployment occurs" for the TeamSite based comparison. How does it matter where the comparison is taking place because the'd have to exchange information to compare files anyway!
Thanks,
-Cliffhanger

Find more posts tagged with

Comments

Dwayne

The difference is in how the comparison is accomplished.

In a directory-based comparison, each file needs to be checked, one at a time, source to destination, to determine which files to send

In a TeamSite based deployment, TeamSite checks it's already existing, internal log of the differences between the two areas. There is no actual comparison of the individual directories. TeamSite already "knows" what's different - OD is just leveraging that information.

--

Current project: TS 5.5.2/6.1 W2K

cliffhanger

Thank you dwayne, but where does it store the internal log then?
-Cliffhanger

Adam Stoller

TeamSite based deployments perform the comparison on the TeamSite server between 'area' and 'previousArea' - and this essentially results in a file list that is just pushed to the target server.

Difrectory based differences are where the comparison is performed between the source area on the Base Server and the target area on the Receiver (or receiving Base Server) and as such you are performing a diff accross the network as opposed to just on the local machine.

Does that help clarify things?

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

Adam Stoller

There's an in-memory log which can be access with a DNR or there's the written log which is generally in ODHOME/log/

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

Migrateduser

Something to keep in mind regarding TeamSite-based comparisons is that the 'previousArea' should accurately reflect the state of the target server(s) prior to deployment. Otherwise you may not get the results you expect.

In other words, if a file were removed from the target manually, the fact that the file is missing would not be reflected in the results of a TeamSite-based comparison (i.e., it wouldn't appear in the manifest.) However, an actual directory comparison (done over the network) would detect the file is missing and include it in the manifest of files to be deployed.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Dwayne

where does it store the internal log then?

Do you mean where does TeamSite store it, or where does OpenDeploy store it?

In the case of OpenDeploy, as Fish said, there's an in-memory log of the files to be sent. But I suspect you mean where does TS store it.

And I really can't answer that question, other than to tell you "in the backing store." That's far down into the "guts" of TeamSite, and has never been made public. I used to be an Interwoven employee, and I never had access to that sort of information.

My guess is that, at a high level, TS is maintaining a list somewhere that says "between editon a and edition a+1, the following files changed ...". So when OD wants to do a TS-based deployment, it simply needs to "add up" all of the differences between the two selected areas.

Now, it's possible that it isn't done this way, that it's actually just that each area (edition) has a list of all of the nodes (files/directories) and their corresponding version number. So when OD does the deployment, it's comparing these two lists, looking for differences. But that's still orders of magnitude faster than doing a directory comparison. Directory comparisons require, at minimum, two disk accesses (one on the source, one on the destination) per directory, plus network traffic between the boxes. Comparing two lists is just two disk accesses.

--

Current project: TS 5.5.2/6.1 W2K

cliffhanger

Hi Ghoti,
Yes is does clarify my confusion about their differences, but created another question- in teamSite based if it compares 'area' and 'previousArea' then where is the log file coming into play? It also seems like, with teamSite comparison it's assuming next-to-latest edition was the one to get deployed previously, and hence it compares it with the latest edition, and deploys the difference. Isn't it risky to do so? What if the next-to-latest edition is not the one that was deployed last? Or is it that information i.e. the last deployed edition and the target host name is what it takes from the log file.
Thanks for your help.
-Cliffhanger

Dwayne

You are quite correct. See tscallan's post about this subject.

If you're going to use TeamSite-based deployments, you need to be very sure you have absolute control over the deployment process, so that you don't run into situations like this. Because OD does not ""keep track" of the last deployed edition. It's just assuming that the previous edition was the one that was deployed.

For that reason, I rarely recommend using TS-based deployments. While it's the most "light-weight" it's also the most risky.

--

Current project: TS 5.5.2/6.1 W2K

cliffhanger

Thanks to all of you, now it all makes sense.
-cliffhanger

nipper

One more bit of trivia, for date deployments the time stamp comparison is done on the receiving end,
so that is your production web server. Thus for very large sites (and frequent deployments) you could
put a non-trivial amount of extra load on your production server.

Andy