RhodeCode Powers Police System for Crash Reports

Published on August 29, 2013, by Sebastian


This article is part of our series where users speak about their experiences with RhodeCode Enterprise and how they use it in their day-to-day work. Today’s interview is with Michael Davis (MD) from the Center for Advanced Public Safety, answering question asked by Sebastian Kreutzberger (SK), CEO at RhodeCode.

Michael Davis SK: Michael, please tell me a little bit about your organization and yourself.

MD: I am a senior developer at the Center for Advanced Public Safety at the University of Alabama. We develop software for various state and federal government agencies, primarily related to the areas of law enforcement and traffic safety, but we’ve also begun to branch out into other areas, such as health care and social services.

In my case, among several other projects I work on, I’m the lead developer for our eCrash project. eCrash is an application used by police officers and their supervisors to complete, submit, and manage traffic crash reports electronically. eCrash is currently used by nearly every law enforcement agency in the state of Alabama, and we’ve recently begun work on a new version for the state of Arkansas. I also informally act as the administrator of our Subversion and RhodeCode servers.

SK: Since when are you using RhodeCode?

MD: We started using RhodeCode about a year ago and upgraded now to RhodeCode Enterprise. Most of our code was (and actually still is) in Subversion, except for one team that has been using TFS. Some of us were interested in getting started with a more modern version control system, and we were particularly interested in Mercurial, since it seemed to have better tool support on Windows than Git.

SK: Why did you choose RhodeCode and how is the outcome?

MD: We needed something that would allow us to manage our repositories in a central location, as well has handle authentication and authorization. After searching for a while, I found RhodeCode, which seemed like a perfect fit. One of the most important features to us was the LDAP authentication support, which allowed us to hook it up to our Active Directory so we could use our existing accounts rather than having to keep track of another username and password.

timeline

SK: How many users are actively using it?

MD: Our organization has about 60 developers (around 40 full-time employees and 20 students). Currently, most of our developers are still working on older applications in our Subversion or TFS repositories, so I think only about 10 of us are using RhodeCode regularly, though I’d like to try and get more people using it soon. Most of our projects tend to involve small teams or even just a single developer, so we haven’t gotten a lot of opportunities to take advantage of some of the collaborative features like the code review system, though I’d like to make more use of those, as well.

SK: What are your learnings and did your productivity or other aspects improve?

MD: From the administrative side, RhodeCode has definitely made things easier for me. We have it configured so that our developers can freely create their own repositories as needed. With Subversion, I have to create new repositories for other people myself, so what has tended to happen is that we have one giant repository with dozens of unrelated projects, making it really hard to find anything.

From talking to some of the people on other teams using it, I’d say that being able to move to a DVCS has definitely been an improvement over Subversion. I’ve had to spend a lot of time in the past helping people straighten out problems in their Subversion repositories or working copies due to its poor handling of moves and renames (while it’s gotten better, it’s still not all that great). We don’t have those kind of problems with Mercurial.

From the administrative perspective, the fact that RhodeCode allows me to delegate the administration of individual repositories to other people is a blessing. We don’t have anything like that in our Subversion setup, so I regularly have to set up permissions for new users on projects I’m not involved with. With RhodeCode, the project leads can take care of those tasks themselves, so I only have to worry about the global administration tasks.

SK: What should we improve to make RhodeCode Enterprise even better?

MD: It’d be nice to see a more streamlined installation and upgrade process, if possible. The initial setup took me a while to figure out, and for the first few times I had to upgrade it, I felt like I was having to relearn all of the steps needed. I also had to rely on some additional instructions I found written by other people, and some of those introduced some quirks that make the updates a little more complicated for me.

One recommendation I have is to look into creating a virtual appliance for RhodeCode Enterprise. We use VMs for pretty much all of our development servers, so it would’ve been nice if we’d had a prebuilt VM that we could’ve just dropped in and configured. A BitNami installation package might also be nice. They have a contest to pick what apps to support next, and RhodeCode is one of the choices you can vote for.

SK: Yes, these are great ideas and we actually have all of them already on high priority on our roadmap. Especially the installation and upgrade process needs to become easier and we plan to release an automatic installer soon plus an automatic upgrade notifier including an assistant. This should make upgrades far more convenient. The same goes with VMs, they will make it so much easier to get up and running. And relating Bitnami, dear readers, please vote!

Michael, thank you for your time. It’s great to see RhodeCode being used in so many different fields and I wish you and your team all the best with RhodeCode Enterprise and your projects!

MD: Thanks!


Do you want to attend to that series and speak about how you and your open source project, university, organization or company are using RhodeCode Enterprise? Please contact us!