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

branches vs workareas

Finley

I'm new to Interwoven. I can't get a clear understanding of the differences between branches and workareas. When our setup was branch-subbranch-workarea things worked fine. When the setup was branch-subbranch-workarea-subworkarea things didn't work so well. Should subworkareas not be used? Can someone explain how you should set up the site with branches and workareas when you need have many, many sites and subsites that need to be kept organized?

Find more posts tagged with

Comments

Migrateduser

I'm not new to TeamSite, but I'm new to the concept of "subworkarea". Could you explain in greater detail what you're referring to?

Dave

Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
By the way, I miss Unix terribly.

Finley

We have workareas set up. Below that we have more workareas. This is what is looks like.

START
... Editions
... Workareas <-- marked as a workarea
...ClockApp
........ Editions
.........Workareas <-- marked as a workarea
.............. ClockApp_Workarea <-- marked as a workarea

Edited by Finley on 05/18/05 08:20 AM (server time).

Migrateduser

As I see it, the one big difference is that a common STAGING area exists among all sibling workareas. So, if you want to keep work separate but they might be still logically related, keep them in sibling workareas, whereas if they're not related, keeping them in completely different branches might be a better approach.

I admit that my explanation might have been over-simplified, but here is IW's definition of each. Hopefully, that will shed some light:

In reply to:

Branches
TeamSite provides branches for different paths of development for content. Branches can be related to each other (for example, alternate language versions of the same Web site) or they may be completely independent. Typically, each branch contains all the content for a Web site or a major section of it (such as a department), or a collection of related content (such as the program files for a software application or the image and text files for a book). Branches can be indexed and searched.

A single branch contains archived copies of its content as editions, a staging area for content integration, and individual workareas where users may develop content without disturbing one another. Branches can also contain subbranches, so that teams may keep alternate paths of
development separate from each other. Content can be easily shared and synchronized across branches and subbranches. Users may work on one branch or on several, and the number of branches on a system is not limited.
Branches facilitate distributed workflow because they allow separate teams to work independently on different projects. Because all branches are located on the same TeamSite
server, it is easy for one team to incorporate the work of another into their project.

Workareas
Each workarea contains a virtual copy of all related content, which may be modified in any way without affecting the work of other contributors. Users who have access to a workarea may modify files within that workarea and view their changes within the context of all related content before integrating their work with that of other contributors. Users can lock files in each workarea, eliminating the possibility of conflicting edits.

All changes made to files in a workarea are kept completely separate from other workareas and the staging area until the user chooses to submit his changes to the staging area. Within a workarea, users may add, edit, or delete files, or revert to older versions of files without affecting other users.

Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
By the way, I miss Unix terribly.

Finley

Thanks - that helps

tgerber

We have multiple releases or edits for upcoming releases for a single web site underway simultaneously.

Would we be better off having branches of the web site then merging them together?

Or creating multiple worksareas - lets call them workareaA and workareaB. When we are done and ready to release workareaA we stage that content, remove workareaA and then do a get latest in workareaB and resolve any conflicts? We need to carry workareaA's changes forward into worksareaB so we don't lose workareaA's changes but both workarea's would have been created at the same time.

Thx

Migrateduser

I'd go with option B (the one that was accompanied by a paragraph). Remember that whenever you submit anything to staging, it's automatically versioned, even without explicitly cutting an edition (which is another feature of doing it this way).

Dave

Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
By the way, I miss Unix terribly.

Adam Stoller

What kind of time difference is there between the first and second releases?
What kind of elapsed time is there in the development effort of the two releases?
Do you expect the second release to constantly be updating their working code/content with the work from the first release - or are they to be done independently during development and then merged and re-verified before the second release?

In general, concurrent development of two related by separately managed releases should probably be done in separate branches. Why? Because if you do it in the same branch you will have problems with work from both efforts being submitted to a single staging area, which means the efforts potentially step all over each other - or the second effort has to do all their work without any versioning waiting unitl the first effort is completed (a.k.a. working without a net)

Working with multiple branches is, however, not necessarily a trivial solution - as you need to figure out how to do the branch-to-branch merging; not just the technical aspects of it - but the human aspects, as in *who* performs the merge operation / *who* decides how to resolve conflicts, etc.

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

Herman

If I put the project A in branch_Dev for programer,
then copy the projectA to branch_QA for QA testing.

Two branches for the same project,is it a good design?
any problem will cause?

Adam Stoller

Using multiple branches for the same project as it moves through release processes is fairly standard practice for software development.
Using multiple branches for the same procect as it moves through release processes is less standard practice for web content development.
If your project is essentially web development with embeded application development - then it probably makes sense to develop a multi-branch solution.
If your project is static web content without embeded application development, it *usually* only makes sense to bring in a second branch when working on a site overhaul, otherwise it *usually* can be handled fairly easily within a single branch ("usually" means just that - and not "always")

There is always potential for problems.
What you need to do is work out the *entire* process as part of a *design* - then work on implementing and testing it to verify that it works as desired without any [easily found] problems.

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

jkm

Hi All,

Need some suggestions when shall we keep our site in single branch or multiple branches?

We want to provide content security by giving different accesses to different content owners. Say in our site I have five top level content areas
a1,b1,c1,d1,e1 and user ua1 will have access to content of a1, ub1 will have access to b1 and so forth.. We can achieve this content security by keeping the content under single branch and giving different folders permissions and same thing can be achieved using multiple branches as well.

What is the edge of using multiple branches of TS instead of single branch here? Is this a good practice to give different permissions and groups under same branch?

Please let me know.

regards

Adam Stoller

Hi All,

Need some suggestions when shall we keep our site in single branch or multiple branches?

We want to provide content security by giving different accesses to different content owners. Say in our site I have five top level content areas
a1,b1,c1,d1,e1 and user ua1 will have access to content of a1, ub1 will have access to b1 and so forth.. We can achieve this content security by keeping the content under single branch and giving different folders permissions and same thing can be achieved using multiple branches as well.

What is the edge of using multiple branches of TS instead of single branch here? Is this a good practice to give different permissions and groups under same branch?

Please let me know.

regards

Well, my thoughts are:

If you go the multiple-branch route and you have inter-dependencies, you need to set up iwproxy directives to acheive a sense of "one-ness" when previewing the content.

nipper

Hi All,

Need some suggestions when shall we keep our site in single branch or multiple branches?

We want to provide content security by giving different accesses to different content owners. Say in our site I have five top level content areas
a1,b1,c1,d1,e1 and user ua1 will have access to content of a1, ub1 will have access to b1 and so forth.. We can achieve this content security by keeping the content under single branch and giving different folders permissions and same thing can be achieved using multiple branches as well.

What is the edge of using multiple branches of TS instead of single branch here? Is this a good practice to give different permissions and groups under same branch?

Please let me know.

regards

Hard to answer this in a couple of posts. This is usually something a SR consultant would spends days or even a week on.

What are the needs of preview ? Do you want to see the changes of both in context of a complete site ? Are templates used ? Are they used across multiple directories ?

From what you have said so far, a single branch is probably better. But you had better have a solid workflow with update task. Most single branch with mutiple workareas I have seen are in serious trouble with consitancy. People do not do a get latest (and really should not have to). So I tend to do multiple branches with 1 WA each. However that has some issues as well.

There is not a one size fits all answer.

Andy

jkm

Thanks Adam for your reply.
We are thinking upon exactly similar lines. Because to mantain content under different branches will be bit hard and as you have rightly put to provide proxy rules to make complete site under one tree.
Only issue I was thinking that single branch is not very scalable and if site grows in future then to migrate the content from one branch to multiple branches will be difficult which can be achieved easily when site is in it's inception state.

Adam Stoller

Thanks Adam for your reply.
We are thinking upon exactly similar lines. Because to mantain content under different branches will be bit hard and as you have rightly put to provide proxy rules to make complete site under one tree.
Only issue I was thinking that single branch is not very scalable and if site grows in future then to migrate the content from one branch to multiple branches will be difficult which can be achieved easily when site is in it's inception state.

As Nipper said - there's no one-size-fits-all answer, especially based on limited information. If you really think the site (or components of the site) are going to grow substantially - then you might lean towards the multiple branch solution - but keep in mind that many TS systems are set up with tens of thousands of assets within a single branch (divided over multiple directories and sub-directories and such) - hence the emphasis on "substanially". Otherwise it's not a major factor in the decision and the other issues are still the major factors.

jkm

Agreed Adams, This can not be completely defined in forum because of the limited information but your reply gives us good amount of confidence to think that content can be managed using single branch as well but it can vary from system to system.