RE: Migration from StarTeam to Subversion

Here is where I'm wondering how far you can get with Trac for Subversion..
I've had a look at the system, and I've even set it up for test purposes,
but not yet had time to play around with it much.

It does seem to provide decent integration and reporting, but I didn't have
any issues like the ones below in mind when I started to look at it. Not
that I think this will become an issue, but it would be interesting to know
how it compares, for example, to the features / integration of StarTeam.
Does anyone out there use Trac "for real", and if so, what's it like?

Regards,

--
Johan Wärlander
e-mail: jwarlander@sjm.com
phone: +46 (0)8 474 4701 / +46 (0)73 9737 805
St Jude Medical AB
Veddestavägen 19
175 84 Järfälla
Sweden
-----Original Message-----
From: Hakan Koseoglu [mailto:hakan.koseoglu@pcmsgroup.com] 
Sent: den 11 maj 2004 15:22
To: Jay Glanville
Cc: users@subversion.tigris.org
Subject: RE: Migration from StarTeam to Subversion
Hi,
We use Starteam at work as well so here's my $0.02 worth...
> 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.
We have a similar process, the branching of the bugs make perfects
sense, a bug might be fixed in one branch but not fixed on the other due
to many factors. On the other hand, this didn't make any sense to 
Develompent and Mgt. teams. They just couldn't understand how on earth a
bug can be both fixed and not fixed.
There are some problems like you actually cannot find if a bug has been
fixed on any of the branches unless you go through the reporting stage
you outlined. On the other hand, if a development team is working on a
particular branch (which makes sense if you are working on multiple
branches as we do), it is easier to see what's fixed or needs fixing.
Also as long as the changes are propogated to the main trunk from the
branches, the fix rate increases. Also there are bugs you don't want to
fix due to resourcing or the simple fact that no one is using the
branch, you really want to leave them alone.
Systems like Bugzilla really don't work when you have connected
branches, Starteam provides the functionality but the user interface is
far too complicated and some simple things are not possible without
going through time-consuming reporting work.
> However, you can only create links within the _same_ branch.  This is
> the problem.
Are you sure about this? You can create a link across the
projects/branches/views, what kind of link are you trying to create? The
only problem I found was you can't modify a CR and refer to a label in a
different branch.
> 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.
There are a couple of ways to go around this problem, one is using the
external info fields and populating them with some values like the
branch and build number you were working with. QA staff checking the CR
would note this down and verify it against the correct branch.
To be fair, we are in a similar mess but our problem is mainly due to
the Starteam's UI and usability problems + Mgt. At the moment we have a
process where a QA member actually reconciles the CRs between projects.
IMHO, this is a waste of resources and a very very dull job. This is
done just to enable Mgt. to have a look at one branch and deduct the
state of all bugs but it is not logical, it really doesn't work
efficiently either.
> 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.)
Revisions are not that useful, I usually can't find in which branch a
file is in just by looking at its revision information. All of our
classes contain a revision information method which is expanded by
Starteam so theoretically it works, practically (especially once you
start branching heavily), it becomes unusuable.
> 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.
This is an extremely hard thing to do with Starteam. We have a utility to
check the classes changed between two builds (we use CruiseControl to
generate automated builds), Cruise Control's log helps to a degree but it is
not usable if you are comparing two different builds with, say, 5 builds
between.
> 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.
I find that StarTeam's problems are usually process-problems or
usability (GUI) problems. It is not the most intuitive application to
use. 
I investigated Subversion as a possible replacement but at least for
now, it is not an option. It and its siblings do not provide the
integration we came to be used to but StarTeam itself is not the perfect
solution either, actually it is quite far from it.
For my own work, Subversion is good and I'm using it at home on my own
projects.
Best regards,
-- 
Hakan Koseoglu
PCMS Datafit Ltd.
3 Avro Court
Ermine Business Park
Huntingdon
Cambs PE29 6XS
Tel: +44-1480-435436
Fax: +44-1480-434012
Disclaimer: Any resemblance between the above views and those of my
employer, my terminal, or the view out my window are purely
coincidental.  Any resemblance between the above and my own views is
non-deterministic.  The question of the existence of views in the
absence of anyone to hold them is left as an exercise for the reader.
The question of the existence of the reader is left as an exercise for
the second god coefficient.  (A discussion of non-orthogonal,
non-integral polytheism is beyond the scope of this article.)
________________________________________________________________________
The information contained in this e-mail is intended only for the person
or entity to which it is addressed and may contain confidential and/or
privileged material. If you are not the intended recipient of this
e-mail, the use of this information or any disclosure, copying or
distribution is prohibited and may be unlawful.
If you received this in error, please contact the sender and delete the
material from any computer.
The views expressed in this e-mail may not necessarily be the views of
The PCMS Group plc and should not be taken as authority to carry out any
instruction contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
***************************** 
This communication may contain information that is proprietary, privileged,
confidential or legally exempt from disclosure.  If you are not a named
addressee, you are notified that you are not authorized to read, print,
retain, copy or disseminate this communication without the consent of the
sender and that doing so may be unlawful. If you have received this
communication in error, please notify the sender via return e-mail and
delete it from your computer. Thank you. St. Jude Medical, Inc. 
*****************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org