Starteam migration to Subversion

At work we have been using Borland's Starteam for a while for our SCMS (Source Code Management System).  I don't know it is good or bad, as we have simple team, but when I asked for additionnal licences, I found out that their prices are very high: 1 Named user: 750$, 1 Concurrent user: 3900 (discounted by 50% at the moment I asked for a quote).  And add to that 22% yearly maintenance cost.

As we already started using Subversion for other projects, we decided to move from Starteam to Subversion for all of our projects, but our concern was of course how to import all the project versions from Starteam to Subversion.  Thanks to a nice company named Polarion, it is possible with their svnimporter tool http://www.polarion.com/downloads/svn.php.  This tool is available to migrate from other SCMS to Subversion with support for CVS, PVCS, VSS, ClearCase, MKS and Starteam.

It took me some time to figure out how to run the tool (which is java-based).  At first I just used the tool and dumped data on my own Windows workstation, but when I tried to load the data on my Linux svn server, I got errors.  Also, apparently the Starteam implementation has problem with Starteam tags, but I didn't mind and set it to import the trunk only.  Finally, I managed to run it on my Linux svn server easily and it creates the repo automatically and loads the data in it.  Our biggest project took 88 to import.


Comments

Leo said…
Planning to do that here...
Can you post how did you manage to do? Mini how to?
8:58 AM
ugob said…
Did you download the tool? It is quite self-documented. You have to edit a comfig file and start the command... At first I tried it on my Windows PC, but found out it was easier directly on my Linux-based SVN server.

If you have specific questions, please let me know.
3:06 PM
Post a Comment

Popular posts from this blog

General linux performance troubleshooting

Here's a list of commands that you should execute and then share the output to someone who can help you figure out what resource is the bottleneck in your system. Note, it requires the  sysstat  and  procps  packages (ubuntu and RHEL and its derivatives): uptime vmstat 1 10 iostat -xN 2 10 mpstat -P ALL 3 10 pidstat 1 10 free -mw (or free -m, if your OS doesn't support -w)  uptime is to see the load averages on the system. vmstat is mostly used to tell if the system is swapping or not. If you see significant numbers in the 'si' and 'so' columns, your system is most likely swapping (using the hard drive as RAM), which usually slows performance a lot. iostat is mostly used to determine if your disk subsystem is not able to cope with the load. If you see one or more lines that shows 100 or close almost constantly, it is probably the case.  If it is your swap volume, you probably saw numbers in the 'si' and 'so' columns in the  vmsta...
Read more

Networker automated recovery testing using the REST API - introduction

One feature that is lacking from Networker, compared to some of its competitors, is the built-in automatic recovery testing. However, when there's an API, there is a way.  Networker's REST API is not perfect, but it allows the backup administrator to perform queries about Networker resources (objects). As my workload is going up, I realize that one of the tasks that I tend to skip the most is the periodical recovery tests.  Don't forget that a a backup that is not tested should be considered non-successful. I also found out that my recovery tests were not diverse enough. When I started this project, I knew a little bit about REST APIs, and nothing about JSON processing. With the Networker REST API documentation, and the help of a friend and Networker Support staff, I was able to create HTTP queries with Postman,  cURL and jq . Once I got the queries that I needed, I put them in a bash script that would somehow select one backup, and then restore it. My first attem...
Read more

Tips for being a better system administrator

Here are a few tips that I have discovered or implemented during my career, that can help anyone get better results: Follow the 3-2-1 backup strategy  or better 3 copies of the data 3 different media 1 copy offsite Test your backups regularly. Ideally, automate your recovery tests. Use Whatever-as-code as much as you can. IaC is the first that comes to my mind, but using code to define objects and their properties have several advantages: Auto-documentation of changes Ability to easily rollback (using source code management like Git) Makes it easier for standardization an compliance Ansible, Chef, Puppet, Salt, Terraform, Pulumi are good examples Maintain a changelog of all the major changes in your infrastructure (that isn't already "documented" because you're using IaC). Keep track of your hardware inventory and plan your renewals and warranty extension purchases. Build a spreadsheet with all the components that you manage and make sure that everyone on the sysadmi...
Read more