Board index » off-topic » Project/View organization

Project/View organization


2006-04-06 11:30:30 PM
off-topic13
I have read through the StarTeam Best Practices white paper
(which could probably use some updating since the date is
Dec 2003) and so I know what it says but I would like to know
how others are using StarTeam for their project and view
organization.
The white paper says a project should be used for a cohesive
application set or application component set. I guess you
could also use the term product.
So, does anyone else have a lot of products or applications
that results in a large number of projects? Or, do you lump
your products together under fewer projects so your projects
represent a product or application family?
And, then use the views to represent different products or
applications within that family?
Do you have extensive code re-use across your products or
even between product lines? How do you re-use ("share") that
code between all of the products?
Is sharing done at a source code level? Libraries? Integrated
into the build process?
Thanks for your feedback.
 
 

Re:Project/View organization

Quote
So, does anyone else have a lot of products or applications that
results in a large number of projects? Or, do you lump your products
together under fewer projects so your projects represent a product or
application family?

And, then use the views to represent different products or
applications within that family?

In my case I've got about 8 products that depend in different degree on a
single database. As well I've got Setup and Updater projects that I've placed
into different projects. There are also a few other products separated from
each other into different projects in StarTeam.
Why I choose such shema? Those 8 projects are depended on database's structure
and store procedures. In our current environment it's very hard to handle
database version by itself and versions of products themselves. This way
I can place a view label on a consistent set of projects that depending on
the same database state. So I can place a view label like Release_2.3.226
and if it's needed I can adjust revisions of some files in that label. If
I need to check out a product I can use profiles on the clieant side or reference
views on the server side. I prefer profiles because it's ease to adjust.
So my developers have profiles like Product1 containing the Product1 folder
and Database folder. And so on.
Setup project is almost constant. Updater as well.
Quote
Do you have extensive code re-use across your products or even between
product lines? How do you re-use ("share") that code between all of
the products?

Is sharing done at a source code level? Libraries? Integrated into
the build process?
I try to avoid sharing any way. It's seems nature to hold labraries in different
project and share it into other projects but I prefer other way. I keep dependences
of a project in an xml file and use it in a "prepare workspace" script. This
way I can check out a project with different versions of libraries (debug/release),
static/dynamic for the same project depending on the task (release build
of a product or developer workstation). The similar way I can configure necessary
for development database and diploy it during "prepare workspace" script.
Quote

Thanks for your feedback.

You welcome.
 

Re:Project/View organization

thanks for the response Mike. We have more than 8 products on
one team. We make embedded consumer products that span several
markets (across all the teams) and let's just say we are
prolific about developing products. We probably have 75-100
active products (plus all of the discontinued products). If
we did those as seprate projects, that makes for quite a few
projects. As it is, we use projects to separate the product
families and then views are used for the individual products.
There is a heavily shared code base and yes, thanks to the
ease at which StarTeam allows file sharing, they chose to share
that code base at the source level. So, we have some files
shared across almost all the views and projects.
That is why I am interested in what others have done so I
can give them some alternative examples.
Mike Eshva < XXXX@XXXXX.COM >wrote:
Quote
>So, does anyone else have a lot of products or applications that
>results in a large number of projects? Or, do you lump your products
>together under fewer projects so your projects represent a product or
>application family?
>
>And, then use the views to represent different products or
>applications within that family?
>
In my case I've got about 8 products that depend in different degree on a
single database. As well I've got Setup and Updater projects that I've placed
into different projects. There are also a few other products separated from
each other into different projects in StarTeam.
Why I choose such shema? Those 8 projects are depended on database's structure
and store procedures. In our current environment it's very hard to handle
database version by itself and versions of products themselves. This way
I can place a view label on a consistent set of projects that depending on
the same database state. So I can place a view label like Release_2.3.226
and if it's needed I can adjust revisions of some files in that label. If
I need to check out a product I can use profiles on the clieant side or reference
views on the server side. I prefer profiles because it's ease to adjust.
So my developers have profiles like Product1 containing the Product1 folder
and Database folder. And so on.
Setup project is almost constant. Updater as well.

>Do you have extensive code re-use across your products or even between
>product lines? How do you re-use ("share") that code between all of
>the products?
>
>Is sharing done at a source code level? Libraries? Integrated into
>the build process?
I try to avoid sharing any way. It's seems nature to hold labraries in different
project and share it into other projects but I prefer other way. I keep dependences
of a project in an xml file and use it in a "prepare workspace" script. This
way I can check out a project with different versions of libraries (debug/release),
static/dynamic for the same project depending on the task (release build
of a product or developer workstation). The similar way I can configure necessary
for development database and diploy it during "prepare workspace" script.

>
>Thanks for your feedback.
>
You welcome.


 

{smallsort}

Re:Project/View organization

Ron,
Given the number of products I probably would do like you have done.
How are your product views setup within a family project?
:) dave
"Ron Summers" < XXXX@XXXXX.COM >wrote in message
Quote

thanks for the response Mike. We have more than 8 products on
one team. We make embedded consumer products that span several
markets (across all the teams) and let's just say we are
prolific about developing products. We probably have 75-100
active products (plus all of the discontinued products). If
we did those as seprate projects, that makes for quite a few
projects. As it is, we use projects to separate the product
families and then views are used for the individual products.
There is a heavily shared code base and yes, thanks to the
ease at which StarTeam allows file sharing, they chose to share
that code base at the source level. So, we have some files
shared across almost all the views and projects.

That is why I am interested in what others have done so I
can give them some alternative examples.


Mike Eshva < XXXX@XXXXX.COM >wrote:
>>So, does anyone else have a lot of products or applications that
>>results in a large number of projects? Or, do you lump your products
>>together under fewer projects so your projects represent a product or
>>application family?
>>
>>And, then use the views to represent different products or
>>applications within that family?
>>
>In my case I've got about 8 products that depend in different degree on a
>single database. As well I've got Setup and Updater projects that I've
>placed
>into different projects. There are also a few other products separated
>from
>each other into different projects in StarTeam.
>Why I choose such shema? Those 8 projects are depended on database's
>structure
>and store procedures. In our current environment it's very hard to handle
>database version by itself and versions of products themselves. This way
>I can place a view label on a consistent set of projects that depending on
>the same database state. So I can place a view label like Release_2.3.226
>and if it's needed I can adjust revisions of some files in that label. If
>I need to check out a product I can use profiles on the clieant side or
>reference
>views on the server side. I prefer profiles because it's ease to adjust.
>So my developers have profiles like Product1 containing the Product1
>folder
>and Database folder. And so on.
>Setup project is almost constant. Updater as well.
>
>>Do you have extensive code re-use across your products or even between
>>product lines? How do you re-use ("share") that code between all of
>>the products?
>>
>>Is sharing done at a source code level? Libraries? Integrated into
>>the build process?
>I try to avoid sharing any way. It's seems nature to hold labraries in
>different
>project and share it into other projects but I prefer other way. I keep
>dependences
>of a project in an xml file and use it in a "prepare workspace" script.
>This
>way I can check out a project with different versions of libraries
>(debug/release),
>static/dynamic for the same project depending on the task (release build
>of a product or developer workstation). The similar way I can configure
>necessary
>for development database and diploy it during "prepare workspace" script.
>
>>
>>Thanks for your feedback.
>>
>You welcome.
>
>

 

Re:Project/View organization

I have only been here a year and a half so it wasn't
my decision. That is the way they decided to set it up.
I have recently had some requests about "reorganizing"
the views and projects. This is very difficult with StarTeam.
Some of those requests are because they want to "move" a
particular product's development but intact. Anyway, I think
you can appreciate the difficulty of doing that in StarTeam.
I wish they had a more flexible repository but I can see why
they can't given their architecture.
I'm not sure exactly what information you are looking for in
regards to your questions on how the product views are set up
within a family project but let's see if this is close.
For a given StarTeam project that represents a product family,
there generally is not anything in the root view. Sometimes,
someone will stick code files they want to share across the products in the root view.
All of the views under the root view are created as non-derived
(blank) views. Each of these views are usually a single
product's main development view. We don't try to use the view
hiearchy too much to do deep organization.
For each development view, we usually create a derived release
view as branch none, floating. This is so any changes in the
development view flow down to the release view. We do have to
do some trickery to stop files added in the release view (for
a specific fix) from floating up and down. Also, so that CRs
are only created in the development view and accessed (fixed)
in the release view.
There are some issues with this, like a massive file change in
development can cause confusion in the release view when you
are trying to just work on the release. Because of this, some
groups are trying some different tactics (which I won't go in
to right now).
That's our basic setup but some people have some issues and
so we are looking at changing some of the ways we are doing
things.
Hope that addressed your question.
"David Hegland" < XXXX@XXXXX.COM >wrote:
Quote
Ron,

Given the number of products I probably would do like you have done.
How are your product views setup within a family project?

:) dave



"Ron Summers" < XXXX@XXXXX.COM >wrote in message
news:443bd9d4$ XXXX@XXXXX.COM ...
>
>thanks for the response Mike. We have more than 8 products on
>one team. We make embedded consumer products that span several
>markets (across all the teams) and let's just say we are
>prolific about developing products. We probably have 75-100
>active products (plus all of the discontinued products). If
>we did those as seprate projects, that makes for quite a few
>projects. As it is, we use projects to separate the product
>families and then views are used for the individual products.
>There is a heavily shared code base and yes, thanks to the
>ease at which StarTeam allows file sharing, they chose to share
>that code base at the source level. So, we have some files
>shared across almost all the views and projects.
>
>That is why I am interested in what others have done so I
>can give them some alternative examples.
>
>
>Mike Eshva < XXXX@XXXXX.COM >wrote:
>>>So, does anyone else have a lot of products or applications that
>>>results in a large number of projects? Or, do you lump your products
>>>together under fewer projects so your projects represent a product or
>>>application family?
>>>
>>>And, then use the views to represent different products or
>>>applications within that family?
>>>
>>In my case I've got about 8 products that depend in different degree on a
>>single database. As well I've got Setup and Updater projects that I've
>>placed
>>into different projects. There are also a few other products separated
>>from
>>each other into different projects in StarTeam.
>>Why I choose such shema? Those 8 projects are depended on database's
>>structure
>>and store procedures. In our current environment it's very hard to handle
>>database version by itself and versions of products themselves. This way
>>I can place a view label on a consistent set of projects that depending on
>>the same database state. So I can place a view label like Release_2.3.226
>>and if it's needed I can adjust revisions of some files in that label. If
>>I need to check out a product I can use profiles on the clieant side or
>>reference
>>views on the server side. I prefer profiles because it's ease to adjust.
>>So my developers have profiles like Product1 containing the Product1
>>folder
>>and Database folder. And so on.
>>Setup project is almost constant. Updater as well.
>>
>>>Do you have extensive code re-use across your products or even between
>>>product lines? How do you re-use ("share") that code between all of
>>>the products?
>>>
>>>Is sharing done at a source code level? Libraries? Integrated into
>>>the build process?
>>I try to avoid sharing any way. It's seems nature to hold labraries in
>>different
>>project and share it into other projects but I prefer other way. I keep
>>dependences
>>of a project in an xml file and use it in a "prepare workspace" script.
>>This
>>way I can check out a project with different versions of libraries
>>(debug/release),
>>static/dynamic for the same project depending on the task (release build
>>of a product or developer workstation). The similar way I can configure
>>necessary
>>for development database and diploy it during "prepare workspace" script.
>>
>>>
>>>Thanks for your feedback.
>>>
>>You welcome.
>>
>>
>


 

Re:Project/View organization

I'm not a profi in StarTeam but as long I can see you have turn everything
inside out. I mean the ideology of StarTeam. Too many hand work.
Quote
I have only been here a year and a half so it wasn't
my decision. That is the way they decided to set it up.
I have recently had some requests about "reorganizing"
the views and projects. This is very difficult with StarTeam.
Some of those requests are because they want to "move" a
particular product's development but intact. Anyway, I think
you can appreciate the difficulty of doing that in StarTeam.
I wish they had a more flexible repository but I can see why
they can't given their architecture.
I'm not sure exactly what information you are looking for in regards
to your questions on how the product views are set up within a family
project but let's see if this is close.

For a given StarTeam project that represents a product family, there
generally is not anything in the root view. Sometimes, someone will
stick code files they want to share across the products in the root
view.

All of the views under the root view are created as non-derived
(blank) views. Each of these views are usually a single product's
main development view. We don't try to use the view hiearchy too much
to do deep organization.
Non-derived views are not recommended. Why don't you use project family root-view
like a common folder for all projects? If you need to separate developers
of different products why you don't use reference views?
Quote

For each development view, we usually create a derived release view as
branch none, floating. This is so any changes in the development view
flow down to the release view. We do have to do some trickery to stop
files added in the release view (for a specific fix) from floating up
and down. Also, so that CRs are only created in the development view
and accessed (fixed) in the release view.
Why you do use branch none floating views? Development view and release view
are different conception. Development view is for some long-time work that
possibly will not be incorporated into mainline or something similar. Release
view is almost freezzed version of a product. It should receive only critical
updates. Usually you don't want to change anything in it.
Floating means that you cannot control the time you get changes in other
views. That means someday you'll get mistically broken build. View merge
is much better. At least you can control the time of the mess. :)
May be you do branch new release line from prior release branch. If so you
do the worst to my mind.
Quote

There are some issues with this, like a massive file change in
development can cause confusion in the release view when you are
trying to just work on the release. Because of this, some groups are
trying some different tactics (which I won't go in to right now).

That's our basic setup but some people have some issues and so we are
looking at changing some of the ways we are doing things.
Try to read best practices about organizing StarTeam projects and views.
There is some old but actual document.
Best regards
 

Re:Project/View organization

Ron Summers wrote:
Quote
<snip>
So, does anyone else have a lot of products or applications
that results in a large number of projects?

We make it so the source for every binary is its own StarTeam
project. Then, we make a separate project for the product and share
the root folders of the individual binary source into it. This gives
us what we call the Build Project.
Quote
And, then use the views to represent different products or
applications within that family?

For custom builds, we make branchable derived Views of the Build
Project.
Quote
Do you have extensive code re-use across your products or
even between product lines? How do you re-use ("share") that
code between all of the products?

When the same source file is used in different binaries, we share
the source code from the home source project using StarTeam's item
sharing feature. If we have multiple Products and reuse is at the
binary level, we share the source project into the build project for
that product.
Quote
Is sharing done at a source code level? Libraries? Integrated
into the build process?

Yes.
Quote
Thanks for your feedback.
No problemo!
Bill House
 

Re:Project/View organization

That was some great feedback. I'll have to see
if any of this can be applicable to our situation.
Thanks.
Bill House < XXXX@XXXXX.COM >wrote:
Quote
Ron Summers wrote:
><snip>
>So, does anyone else have a lot of products or applications
>that results in a large number of projects?
>

We make it so the source for every binary is its own StarTeam
project. Then, we make a separate project for the product and share
the root folders of the individual binary source into it. This gives
us what we call the Build Project.

>And, then use the views to represent different products or
>applications within that family?
>

For custom builds, we make branchable derived Views of the Build
Project.

>Do you have extensive code re-use across your products or
>even between product lines? How do you re-use ("share") that
>code between all of the products?
>

When the same source file is used in different binaries, we share
the source code from the home source project using StarTeam's item
sharing feature. If we have multiple Products and reuse is at the
binary level, we share the source project into the build project for
that product.

>Is sharing done at a source code level? Libraries? Integrated
>into the build process?
>

Yes.

>Thanks for your feedback.

No problemo!

Bill House