RE: Migration from StarTeam to Subversion

> From: Toby Johnson [mailto:toby@etjohnson.us]
>
> Jay Glanville wrote:
>
> >- StarTeam has a built in bug tracker. However, the
> integration between
> >it and the source control system is lacking.
> >
> >
> Wow, that is very interesting to know. I just assumed that
> since it did
> both, they were integrated! Thanks for the info...
>
> toby

Just for completes sake, I'll fill you in as to why WE found it lacking.
We are currently using StarTeam as our source repository and our defect
tracker.

First, let me explain that EVERYTHING in StarTeam can be branched:
files, change requests (CRs), requirements, tasks, etc. Not so bad, one
might think: it has it's pros and it's cons. However, quality control
(QC) balked at the resulting process of generating quality reports:
 - open a branch
 - perform the query of the CRs in that branch
 - repeat for all branches
 - aggregate all reports into a single report
It just didn't make sense to them.

In actual fact, when you think of a pairing between SVN and Bugzilla (or
any other stand-alone bug tracker), the files can be branched, but the
bugs can't. This is how we are using StarTeam. I may not be explaining
this as well as I can, but in short, we don't branch our CRs.

Now, StarTeam has the concept of linking file revisions to CRs. It's
even made easy for you: when you check in a file on the checkin form,
you can use the "Link and pin revisions to CR:..." field to create a
link between this file revision and a CR (and even "fix" the CR).

However, you can only create links within the _same_ branch. This is
the problem.

So, we're branching our files, but all our bugs are in the main trunk.
So I'm in the 1.0 (i.e.: not main) trunk, and I've just finished solving
a problem. I'm checking in my changes. However, I can't link my
changes to the CR that I'm solving because they're in different trunks.
(Oh, yea. Trunks == branches.) So, linkage now fails.

The experts at Borland StarTeam looked at our situation, and advised us
to use "Revision Labels" to solve our problem. (StarTeam has both View
and Revision labels. View labels are for loadbuilds, branching roots,
global labeling, etc. Revision labels can be considered "file revision
decorators". You can attach them to a revision of your choice.)

So, when we're checking in changes due to a CR, we have to:
 - create a revision label with the CR# as it's title
 - checkin the file
 - attach the revision label to that revision

Now, there are even some "gotchas" with this system too. Things like
you can only attach a label to one revision of a file. Therefore, if I
changed a file twice for the same CR (I forgot something) then I can
only attach the label to one of the revisions. Another gotcha: what
files were changed to solve CR1234? Well, you now need to go to the
file tree for each _branch_ and try to find all the files with this
label. I.e.: two-way reporting is not easy.

Needless to say, for the way that we're using StarTeam, the integration
is considered to be just as week as if they weren't integrated at all.

Hope you found this useful.

JDG

--
Jay Glanville
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org