Share Branches?

KristerS

My company is planning to add a new site that is separate from the main site in such a way that a user would not realize that either site is related. However, we want to reference some of the same data as a section of the main site (and its DCRs or other digital assets managed by TeamSite, like PDFs, for instance). In fact, we want to be able to create a new DCR and flag it for inclusion on either or both sites...

So, I am trying to figure out the best way to approach this.

I feel that the new site should be an entirely separate branch, but am not sure of the best way to go about sharing the data between the branches, then.

Or should we just leave it as is and rely on an EA to identify whether or not the DCR is for either or both sites?

Is there a good way to accomplish this?

We're running TeamSite 6.5.0 SP 2 on Windows 2003 Server.

Thanks!

Adam Stoller

There is no one-answer-fits-all-circumstances solution here - a lot depends on other aspects of the TeamSite implementation and web site implementation.

There are trade-offs in all the ways I've seen (or suggested) for dealing with such common, or shared, assets - and it's up to the consultant / developer to determine those trade-offs based on the customer's implementation, and the customer to make a decision about which way they want to go.

You could use a "common" branch - and move all shared assets there. This could lead to a completely separate stream of asset development (until it gets deployed), or it could lead to a means of copying the assets into all the other branches that utilize that content.

You could have a "primary" branch that represents the "primary" web site, and then have the common content pushed to other branches - or you could have the other branches pull content from there.

The decision will involve how much you have to configure and use iwproxy on the TeamSite side, perhaps proxying on the web server side, and how you train users in working on the content.

In short - it is not (IMO) an "easy" thing to do - but the solution is (again IMO) very case-specific and not something that someone here can say "here's the one way to do it". You'll have to look at the entire implementation, figure out the ramifications of what you're being asked to do, and present that information to someone else to make a decision about.