Having more branches rather than workareas

All,

Iam new to Teamsiite, I have a question regarding the brahces and workarea. Is it advised to have individual brahces for each department for a website ? My understanding is, it is always good to have only one branch and have workarea for each department. Is this correct ? Is so can you please post the advantages it have over having branches for each department.

thanks in advance.
-m

Find more posts tagged with

Comments

Bryan_K

Its not necessary to have only 1 branch with multiple workareas. We have many branches on our system now. It depends on the level of granularity you need in dividing up who is doing what work. It you have many people all working on 1 site, then you can give each of them their own workarea within a branch for that site. If you have a number of sites, you might consider a branch for each of them. We have many branches with 1 workarea in them, for example.

Bryan

akshathp

For our webproperties, I use "one branch and many workarea" model. That way its easy for me to:
1. Maintain editions.
2. Set Deployments
3. Collaborate content.
4. Workflows and Templates per branch
5. And ofcourse better control of the site with just one staging to sync per site.

Hence I would suggest to have branches based on web properties for your site and workareas based on departments/contributors per web property. For example, if you have web property as your intranet, you could set onebranch as "intranet" and have departments/contributors as Workareas.

Technically you could have multile branches set for one web property. But, logically it will fail at one point or other. I mean, imagine a case where you have multiple branches:

1. You would need to configure deployments for all branches but at the end they will all point to same webserver. So, if a contributor made changes in branch A and there are branches B and C for the same property, how would OpenDeploy know which branch's STAGING to sync.

2. And, if you have templates and workflows for a branch, they are available to entire branch and all the workareas within it. So if you have multiple branches, how will you maintain these workflows and tempaltes.

3. About editions, How would you know which edition of which Branch is the most updated one. As all branches woul dhave their own editions.

4. About STAGING. Again the same point. How would you know which is latest.

Keeping all these factors and many more into consideration I would suggest to go for Vertical design rather then Horizontal. By that I mean, "one branch and many workareas". I guess this should be the design.

Hope this helps!

Akshat Pramod Sharma
Interwoven Inc.

Bryan_K

The whole thing that hangs me up is how to classify a web property. If you classify it as your whole intranet, and you have many different sites on that intranet, all using different templates because their pages do not look the same, and using different workflows because they have different approval processes depending on who their managers are or what the nature of the content is, then it seems to be easier to have multiple branches in this case. Each of the different branches contains different files, which eliminates the staging and edition problems that Akshat is speaking of. Is this a model anyone else has used? Id be interested to know what other people think about this.

Migrateduser

For our intranet, we do pretty much the exact opposite of what you suggest. We have one main branch "intranet" and sub-branches for each department's site. One integration workarea and one qa workarea per site. I have one workflow that is simple and works for all branches. Doing it this way is easy for permissions, as each department has its own contributors and they all have their own "space" they are allowed to play in. I have only one deployment script that determines the target path based on the branch. We only use filelist deployments. Each site has it's own editions, so they are quite easy to maintain. It all works seamlessly.

I think it all depends on what works for your company's design. TeamSite allows everyone to do it however it works for them.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

akshathp

Yes I agree with Dave's point about having a design that best works for your needs. It would primarily depend on what level of contribution, collaboration and approval system you have or want for your sites.

And yes, by web property I meant one individual site which has it's own look and feel and apps. For example, I have a TeamSite server for Intranet that support various sites on our Intranet. All these sites on Intranet I have as branches and all contributors/departments as Workareas within them.

Akshat Pramod Sharma
Interwoven Inc.

elke

That's right, Teamsite allows quite a lot - but generally it is better for performance reasons to limit the number of branches, especially if they are not really necessary. I started with a system with 130 (!!!) branches and had to re-do it, because it was very slow. And especially in our case it was not necessary. It really depends on your needs and you might find yourself re-creating branches/WA's according to your (changing) needs.

Migrateduser

I'm not really sure what kind of performance is limited by the number of branches you have. I can certainly see how the number of files in a workarea could be a performance nightmare - doing a List Modified on a huge workarea takes forever. We haven't seen any performance issues with approximately 150 branches (and growing).

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com