Board index » off-topic » 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.
 

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.
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 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:

{smallsort}

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

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:

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.
like a common folder for all projects? If you need to separate developers
of different products why you don't use reference views?
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.
There is some old but actual document.
Best regards
 

Ron Summers wrote:
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.
Project.
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.
Bill House
 

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: