You Ask, We Answer! 10 Commonly Asked Questions…

Here at Codesion our customers come from a variety of backgrounds. We have expert users that have been running CVS for years, we have Subversion users that have been using it since it was first introduced, we have users that are transitioning from Subversion to Git, and we have many new users that have never used version control With so many levels of expertise, the questions we see on a daily basis run the gamut. Here is a sampling of some of the more recent questions and answers.

Q: What types of files can you store? (e.g. video, files, HTML, .NET, etc..)

A: In short, everything.Any files that you want to version or work on collaboratively can be stored in Codesion. Subversion and Git are file-type agnostic so you can work with text-based source files or with binary files (graphics, videos, etc).If you have a client that can interface with SVN or Git you can work with any files. Click here to read a great blog article discussing how people are using Subversion as version control and storage for many things other than just source code.

Q: What type of backup support does Codesion offer?

A: Our backup system is designed on the philosophy that the customer always owns their data. We make sure their data is always available, secure, and backed up but we also make all of those backups available to our customers.

You can read more about our backup procedure here. We do a hot backup to a dedicated server every 10 minutes, a cold backup to a dedicated datacenter every 24 hours, and we maintain an archive of those cold backups for 30 days; 10/24/30. The likelihood of data loss is very, very slim.

Once we have those backups, we don’t just sit on them, we make them fully available to our Business Plan customers both on demand and through a push mechanism. Customers can go to the Backup tab in their dashboard and either download their backups directly from there or schedule a service for us to push their backups to them via svnsync, rsync, ftp, sftp, or WebDAV. Customers always have the option of maintaining their own data backups.

Q: I need my issue tracker to interface with my source management. I don’t want to be in one application and then have to go to another application to log a fix. How can I do this?

A: Ticket integration is one of the most popular features in Codesion. The Codesion community article describing how to link your repository to your issue tracker is consistently one of the most viewed articles on our site. All commits into SVN, Git, and CVS can update tickets in any of our hosted products: TeamForge, Scrumworks Pro, Bugzilla, and Trac. We also support ticket integrations into third-party issue trackers such as Basecamp, Jira, Rally, VersionOne, etc.

Q: How can I setup RBAC (role based access control) on Git like I can on subversion?

A: One of the great features of Subversion is the ability to apply very specific user roles to different directories. For example, you can give a specific team R/W access to a particular branch in the project but no access or read-only to other branches or the trunk. This gives the project administrator full control of their repositories.

Git, on the other hand, is a Distributed Version Control System (DVCS) and it is meant to be shared. Whenever I think about the Git sharing model I can’t help but think of the lyrics from “Games without Frontiers” by Peter Gabriel:

Hans clones from Lotte, Lotte clones from Jane
Jane pushes to Willie, Willie is happy again.

Git is great for moving code from remote to remote but it doesn’t support the same centralized access model that Subversion will. With so many clones and branches in different locations, how do you manage one repository that is used for builds and deployment? How do you make it so only a few select people can merge changes into the repository?

VP of Engineering Willie Wang, wrote a blog article about the need for a canonical, blessed repository in Git. This repository is used for all new clones (canonical) and for builds (blessed). Within Codesion, each Git repository can be kept in a different Project. Within the Security settings only specific users or roles are granted full R/W access to the blessed repository. Other users can be given read access so they can clone the repository but they cannot push any changes back into it. Users without write access to the blessed repository can work within separate Codesion projects with clones of the repository. The owner of the blessed repository can then manage which branches to merge back to the blessed repository. This Git push from one project to another can now be done from the Codesion Publisher as well.

Q: Do you report on how issues are being logged? I need to be able to get statistics out of issue tracking to see what programs are causing the most issues or are being updated.

A: TeamForge, Trac, and Bugzilla all have varying levels of Reports that can show where the most issues are being logged. ScrumWorks Pro and TeamForge also have Burndown charts and detailed reports to show how the team is tracking against the Sprint Plan.

TeamForge on Codesion, unlike Trac and Bugzilla, also has visibility across multiple projects so you can monitor all of these projects from a single dashboard.

Q: With remote servers, how do I know my performance will be acceptable?

A: Performance is not solely defined bynetwork speed. It is also contingent upon the resources available, the distribution of the team, and the reliability of the server. Many people moving their SCM into the Cloud are transitioning from a Subversion server under-the-desk or have a distributed team.  In the case of the server under-the-desk, Subversion is going to be resource restricted or competing with all other services running on the server. With a distributed team, the users will have to access the repository over HTTP/s and someone will have to manage the firewall access and optimize network bandwidth.

The Codesion Platform is designed from the ground up to be secure, fast and available. We make sure that only you and your users have access to those servers.  We make sure that your repositories are run on hardware optimized and dedicated for the service it is running, whether it be Subversion, Git, CVS, TeamForge, etc. Lastly, we make sure our servers are always available with a high-availability infrastructure, full backups and full system monitoring.

Q: Do you have workflow? I need to have management sign off on things moving to production — with notifications to staff who need to know.

A: TeamForge, Trac, and even Bugzilla all have ticket workflows built in and allow for varying levels of customized workflow. TeamForge, for instance, allows the user to create different workflows for each type of artifact tracked in the project. By default, TeamForge includes Trackers for: Defects, Epics, Stories, Tasks, and Tests. Each of these artifact types can have a different workflow and notification process. In addition, users can create their own custom Trackers and apply a new workflow to that Tracker. The level of customization allows for almost any scenario.

Q: What is the difference between SWP and TFP?

A: TeamForge Project (TFP) focuses on Application Lifecycle Management (ALM) while ScrumWorks Pro (SWP) focuses on Agile Project Management. Okay, but what does that mean?

Both of them allow you to capture product backlog items (PBIs) and plan Sprints. Both of them allow you to report your Sprint and Release progress with Burndown charts or custom reports. In short, both TFP and SWP are designed to improve the agility of your development team and to increase collaboration. The difference is in what you want to accomplish.

TFP also includes a full wiki for information sharing, document storage and versioning, defect tracking for change control, release management, and integration with Hudson for continuous integration. TeamForge is designed to manage the full lifecycle of your products from inception through sunset. It helps to standardize practices and keep everyone on the team informed so they can perform at an optimal level.  Everything the project team needs is in one location.

ScrumWorks Pro on the other hand provides a laser-like focus on the process of Scrum project management. It is meant to let a scrum team practice scrum as efficiently as possible. Product Backlog management is very simple and straightforward while a virtual whiteboard is provided for collaborative task management.

If your goal is to manage all aspects of your development process and begin to standardize across products then TeamForge is probably the better solution. If your goal is to accelerate the adoption of Scrum within your development team or to increase the velocity of an existing Agile team then ScrumWorks Pro is probably the better solution.

Q: Why do you have multiple clients for ScrumWorks Pro (SWP)?

A: SWP has two clients: a Desktop Client and a Web Client. The Desktop Client is a Java Web Start Program that connects to the remote database hosted by Codesion over HTTP. The Web Client is an HTML client that connects to the same remote database hosted by Codesion. They are kept separate based on a division of labor.

The purpose of the Desktop Client is to provide a more robust client to simplify the project management tasks of Scrum. This includes Sprint Team user management, Product Backlog Item (PBI) management, Release and Sprint Planning.

The Web Client is designed as a lightweight client for day-to-day sprint team activities: task creation, task board, impediment tracking, and Burndown reporting.

The goal should be to have your Product Owner and ScrumMaster work within the Desktop Client, while the rest of the sprint team only has to operate in the Web Client.

Q: When should I use Git or SVN for my project?

A: Git versus Subversion has become a hot topic and many people have strong opinions one way or another. Many developers like the ease of use and flexibility of Git while others like the centralized control of Subversion. For us, the answer is simple: use whatever one makes you happy. I highly recommend reading this blog which provides a detailed viewpoint of the strengths and weakness of each between both version control systems.