Board index » off-topic » Using Starteam Views

Using Starteam Views


2005-11-26 12:44:02 AM
off-topic17
I´m new at StarTeam, I have already read some paper and the whole
Administration manual.
I have a question on the use of views. I have read on the paper "Best
Practices on StarTeam" and that is written that it is not recommended to
reach the grandchild views.
I have a doubt on this topic that is:
Imagine that I have a project and I started developing the 1.0 version on
the Main View when I reach the 1.0 release than I will create a Branch All
view called "Release 1.0" and I will continue the development on the main
profile, so I will continue and I reached the 1.1 version, so I create
another Branch All view from the Main View called "Release 1.1". Up to now
my tree structure is the following:
Project
|
|---->"Release 1.0"
|---->"Release 1.1"
Well, now I will start the 2.0 version of my product, but the development
will take some months to complete, like 6 months, during this time I will be
using the Main View to develop the 2.0 version, but my doubt is that, what
if I have to make a release 1.2 to correct bugs from 1.1 and include any
small feature? I will have to make another brach all view, derived from
"Release 1.1"?? If yes, my structure will be:
Project
|
|---->"Release 1.0"
|---->"Release 1.1 "
|
|---->"Release 1.2"
If that is correct, how can I make a 1.3 and 1.4 version if I need to make
those versions during the development of 2.0 that is being made on the Main
View? I will should have the following structure??
Project
|
|---->"Release 1.0"
|---->"Release 1.1"
| |
| |---->"Release 1.2"
| |
| |----->"Release 1.3"
| |
| |---->"Release 1.4"
|
| (After the 2.0 development complete)
|
|---->"Release 2.0"
That is correct??? In this case I will have a lot grandchild Branch All
views.. that is not a problem???
Please Help-me!
Thanks a lot!
Éric Fleming Bonilha
 
 

Re:Using Starteam Views

Éric Fleming Bonilha wrote:
Quote
Imagine that I have a project and I started developing the 1.0
version on the Main View when I reach the 1.0 release than I will
create a Branch All view called "Release 1.0" and I will continue the
development on the main profile, so I will continue and I reached the
1.1 version, so I create another Branch All view from the Main View
called "Release 1.1". Up to now my tree structure is the following:

Project
>
>---->"Release 1.0"
>---->"Release 1.1"

Well, now I will start the 2.0 version of my product, but the
development will take some months to complete, like 6 months, during
this time I will be using the Main View to develop the 2.0 version,
but my doubt is that, what if I have to make a release 1.2 to correct
bugs from 1.1 and include any small feature? I will have to make
another brach all view, derived from "Release 1.1"?? If yes, my
structure will be:
Project
>
>---->"Release 1.0"
>---->"Release 1.1 "
|
|---->"Release 1.2"
[and so on]
Others may disagree, but in general, I would not use branching for the
purpose of marking releases, I use build labels. I would normally only
create a branch if I need to make a special version for some reason (e.g. a
particular customer) so that I can make changes to that branch that will not
(automatically at least) be part of the main view.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The only reason some people get lost in thought is because it's
unfamiliar territory." - Paul Fix
 

Re:Using Starteam Views

Wayne Niddery [TeamB] wrote:
Quote
Others may disagree, but in general, I would not use branching for
the purpose of marking releases, I use build labels. I would normally
only create a branch if I need to make a special version for some
reason (e.g. a particular customer) so that I can make changes to
that branch that will not (automatically at least) be part of the
main view.
One significant question is, do you need to maintain multiple releases
at the same time? If so, I'm not how Wayne's approach would allow this.
We typically maintain two releases while development the next release.
Our next release is our tip. When we release a particular version, we
create a branch for that release.
Now we have the ability to maintain our production releases while
working on the "next big thing" without either effort affecting the
other.
Bug fixes and changes made to maintenance releases that need to be
included in the tip do cause a little extra work. But I've gotten
fairly proficient with StarTeam's view merge so it isn't much work.
And the stability provided by isolating the releases is worth it.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

{smallsort}

Re:Using Starteam Views

Fabio Scognamiglio wrote:
Quote
why branch maintenance release? use of build labels in this case are
more efficient.
I'd always recommend the use of build labels when creating a build of
any type, releasable or otherwise.
I'm assuming you're asking why would 1.1 be branched to create a 1.2?
The reason to create a branch would be to allow changes without
affecting other code paths. So, if there was the need to modify 1.1
without affecting 1.2, the additional branch makes sense to me.
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re:Using Starteam Views

why branch maintenance release? use of build labels in this case are
more efficient.
Should branching be used for very big change like 'evolution' or new
releases? It is correct? what do you think?
fabio.
 

Re:Using Starteam Views

Fabio Scognamiglio wrote:
Quote
Thanks Jon, make sense to me too...
but only if you need multiple maintenance release for multiple
customer with multiple code paths.
Or simply "multiple maintenance release". A single customer would
imply a single maintenance release. A single code path would imply a
single maintenance release. :)
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re:Using Starteam Views

Thanks Jon, make sense to me too...
but only if you need multiple maintenance release for multiple customer
with multiple code paths.
Jon Robertson ha scritto:
Quote


I'd always recommend the use of build labels when creating a build of
any type, releasable or otherwise.

I'm assuming you're asking why would 1.1 be branched to create a 1.2?

The reason to create a branch would be to allow changes without
affecting other code paths. So, if there was the need to modify 1.1
without affecting 1.2, the additional branch makes sense to me.

 

Re:Using Starteam Views

Howdy - I've written a piece about this branching question. For long-term
reference, I've posted it in my StarTeam blog at
starteamanddave.blogspot.com/.
Here it is for your convenience.
Branching Views for Releases
This is my personal recommendation for structuring branches to maintain
multiple releases using StarTeam. This recommendation is not necessarily
consistent with all of Borland's recommendations, but it is pretty close,
and I would argue that it is the best possible hybrid of the various
recommendations from Borland, Starbase, and customers over the years.
Project: MySoftware Major Version 1
...|
...RootViewV1
......|
......MajorRelease1.1
......|....|
......|....MinorRelease 1.1.1
......|....|
......|....MinorRelease 1.1.2
......|....|
......|....MinorRelease 1.1.3
......|
......MajorRelease1.2
...........|
...........MinorRelease 1.2.1
...........|
...........MinorRelease 1.2.2
...........|
...........MinorRelease 1.2.3
In this example, the "MinorRelease" views are "Activity Views" (see the
'Best Practices' paper by Randy Guck for more about Activity Views.)
The minor release activity views are where checkins occur.
The major release views DO NOT get checkins. They only get merged up from
activity views, and those merges only occur around releases. (Root view also
does not get checkins.)
For example, let's say that today I have 1.2.2 in production while we are
developing 1.2.3. All of our new development goes into the 1.2.3 activity
branch. Let's suppose that it is necessary to release some fixes to
production. We check those fixes into 1.2.2, cut a release from 1.2.2, and
1.2.3 is unaffected. Of course we would merge the fix forward to 1.2.3 also,
so 1.2.3 is unaffected _except_ for that merging.
When we are ready to start work on 1.2.4, we would of course, create a new
activity branch called 1.2.4. This activity branch would be a child of
MajorRelease1.2. Naturally, it is very important that we choose the best
configuration in MR1.2 as our basis for 1.2.4. To that end, we should merge
upward from 1.2.2 and also 1.2.3 to get the most current configuration on
which to base 1.2.4.
Ideally, the major release views should contain only the configurations that
we really did release, but sometimes it is convenient to merge up before
releasing in order to facilitate creation of a new activity branch.
If we begin another major release, say 1.3, then we do likewise at the top
leve, merging the latest 1.2 configuration up to the root view and then
creating the 1.3 major release branch.
If it is necessary to work on 3 or 4 or more releases, this branch structure
can accomodate by creating more activity views in the same way. Beware of
creating future activity views and then having to merge the whole world into
them. Don't create them until they are really needed.
This approach is merge-heavy, but careful study of the viewmerge command
line will help with that.
This approach, when combined with CR sharing (see my other post about that)
creates some sticky trade-offs regarding the
"set-shared-items-to-branch-on-change" behavior of the activity view. I
handle that by doing two things. First, all my activity branches are set to
NOT turn on branch-on-change for shared items. This setting is to accomodate
CRs and make them float. Files, then will float (undesirably so) if not
constrained. So, Second thing I do is use the viewmerge command only to
merge existing files. Insofar as any new files must be shared as part of a
merge, I do that sharing manually and also manually ensure that
branch-on-change is set.
This approach really really gets sticky when your developers also want
certain "common" code to float. I would recommend just putting common code
in its own dedicated branch and checking it out on its own, but my
development team is allergic to doing extra checkouts, so I accomodate them
with some tricky dark arts behind the scenes. A full discussion of those
"dark arts" would be lengthy indeed, so let it suffice to say that I use a
few homegrown tools to manage the work of floating a few hundred files while
branching the other thousands of files in the same view. Not easy, and not
recommended, but working well here, fwiw.
For a major version 2, I would create a new project. This is only for major
fundamental restructuring type changes. If the major structure of the code
is largely the same, then I would more likely just increment the major
version number in future branches rather than create a new project.
:) dave
 

Re:Using Starteam Views

Anders Melander wrote:
Quote
"David Hegland" < XXXX@XXXXX.COM >wrote:

>Howdy - I've written a piece about this branching question. For
>long-term reference, I've posted it in my StarTeam blog at
>starteamanddave.blogspot.com/.

No RSS/Atom feed?
Yeah, Dave, jeesh...
It's really easy with Blogger. Check out
help.blogger.com/bin/topic.py
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
www.medevolve.com
 

Re:Using Starteam Views

"David Hegland" < XXXX@XXXXX.COM >wrote:
Quote
Howdy - I've written a piece about this branching question. For long-term
reference, I've posted it in my StarTeam blog at
starteamanddave.blogspot.com/.
No RSS/Atom feed?
--
DIXI
Anders Melander
Software Developer
Denmark
 

Re:Using Starteam Views

Anders Melander wrote:
Quote
>starteamanddave.blogspot.com/.

No RSS/Atom feed?
All BlogSpot blogs have an Atom feed at /atom.xml. So Dave's is at
starteamanddave.blogspot.com/atom.xml
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Please read and follow Borland's rules for the user of their
server: support.borland.com/entry.jspa
 

Re:Using Starteam Views

Anders Melander wrote:
Quote
I thought I had read somewhere on BlogSpot that the blog owner had to
enable feeds before it could be used.
I think it must be on by default, as I've never encountered a BlogSpot
blog which didn't have one.
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from mers.com
 

Re:Using Starteam Views

"Craig Stuntz [TeamB]" < XXXX@XXXXX.COM [a.k.a. acm.org]>wrote:
Quote
All BlogSpot blogs have an Atom feed at /atom.xml. So Dave's is at
starteamanddave.blogspot.com/atom.xml
Excellent, thanks! Works fine.
I thought I had read somewhere on BlogSpot that the blog owner had to enable
feeds before it could be used.
--
DIXI
Anders Melander
Software Developer
Denmark
 

Re:Using Starteam Views

David Hegland wrote:
Quote
Believe it or not I don't know how. Guidance is welcome.
Just link it; you already have the feed.
The simple version is to stick this in your site template somewhere:
<a href="<$BlogSiteFeedUrl$>" title="Atom feed">Site Feed</a>
If you want a picture you can use this one I uploaded for my tin
whistle blog:
photos1.blogger.com/blogger/6376/1061/1600/atom.jpg
Feel free to direct link it, or make your own copy if you prefer.
Here's what I stuck in my template in the top of the sidebar:
<h2 class="sidebar-title">Subscribe</h2>
<a href="atom.xml" title="Atom feed"><img
src="photos1.blogger.com/blogger/6376/1061/1600/atom.jpg"
width=80 height=15 style="vertical-align:middle; padding-top:10;
padding-bottom:10" alt="Atom feed"></a><a
href="learningtowhistle.blogspot.com/2005/05/www-rss-feeds-for-wh
istlers.html">(What's this?)</a>
<p>Search box is at the top of this page.</p>
--
Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from mers.com
 

Re:Using Starteam Views

"Anders Melander" < XXXX@XXXXX.COM >wrote
Quote
No RSS/Atom feed?
Believe it or not I don't know how. Guidance is welcome.
:) dave