RE: Migration from StarTeam to Subversion
From: Warlander, Johan <jwarlander_at_sjm.com>
Date: 2004-05-11 15:42:56 CEST
Here is where I'm wondering how far you can get with Trac for Subversion..
It does seem to provide decent integration and reporting, but I didn't have
-- Johan Wärlander e-mail: email@example.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:firstname.lastname@example.org] Sent: den 11 maj 2004 15:22 To: Jay Glanville Cc: email@example.com 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: firstname.lastname@example.org For additional commands, e-mail: email@example.com ***************************** 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: firstname.lastname@example.org For additional commands, e-mail: email@example.comReceived on Tue May 11 15:44:10 2004
This is an archived mail posted to the Subversion Users mailing list.