Share your experience using Canonical Bazaar

The typical use case for Apache Subversion is to store the application code repositories, which is how we use this product in our company.

For multiple projects, we are using Apache Subversion, and for binary files, once the project is committed, we build the project to create artifacts. We store those artifacts in a separate artifact repository, not in Apache Subversion, because we must keep the minimum storage on the centralized server; otherwise, our repository will grow to a very big size.

I find the strong point of Apache Subversion to be that it is a centralized version control system, allowing us to keep our code repositories at a central server. This means that even if the end user system goes down, we have our code available at the centralized server, and multiple teams can connect together, collaborate, and contribute to the code on Apache Subversion.

The benefit of Apache Subversion to my organization is that we have a platform where we can host our code and maintain the versions of our applications.

There is room for improvement in Apache Subversion, especially when comparing it with other version control systems such as GitHub or GitLab, where many improvements could be made.

Improvements I would like to see in Apache Subversion include configurations, customizations, and functionalities such as those provided by GitHub Actions for immediate pipeline triggers, as well as the version controlling and CI/CD platform offered by GitLab.

In future updates of Apache Subversion, I would like to see CI/CD integrations as well as build and deployment servers.

The lack of latest features includes basic requirements such as pull requests, CI/CD platform integration, and artifact storage such as GitHub packages, which it does not offer.

I have been using Apache Subversion for more than three years.

I deployed Apache Subversion by myself using the Apache documentation, without any help or a team of specialists.

It took me around three to four days to deploy Apache Subversion, because not only the installation but the other repositories configuration I completed took around three to four days.

I have taken support from Apache during the migration from CVS to Apache Subversion initially, but currently, we don't have any active support.

Based on my experience with Apache Subversion's technical support, I would rate it an eight out of ten.

Positive

Before Apache Subversion, we worked with CVS.

As the person who did the deployment of Apache Subversion, I confirm that I was indeed responsible for it.

I have not seen any return on investment or cost reductions after implementing Apache Subversion, as we are currently migrating from Apache Subversion to Bitbucket for the CI/CD integrations and deployment. In terms of pricing, we cannot compare it with any other platform because Apache Subversion is very low in price.

I am satisfied with the pricing and licensing cost of Apache Subversion; it is very low compared to other products.

Currently, we are using a mixed kind of version controlling with Apache Subversion plus Atlassian Bitbucket, and we no longer use CVS.

I have utilized the atomic commits feature in Apache Subversion.

For the development process using Apache Subversion, we integrated it within the IDE, allowing each developer to commit, push code, and pull the code directly from the IDE.

We are using branching and merging functionalities in Apache Subversion.

These branching and merging features help maintain project versions by allowing one of our application teams, which has around 12 to 13 developers working on different feature sets, to create feature branches and separate environments for development, production, UAT, and staging. We have created separate branches accordingly, and the entire deployment process is dependent on those branches. When we push code to the development branch, the development CI/CD pipeline triggers, updating the development branch. Once the work on the development branch is done, we commit to the main branch to release the final version of our application.

Platform independence is important for our use of Apache Subversion; it is independent because our application is hosted on other EC2 instances, while Apache Subversion is completely isolated in different VPCs on AWS.

I rate Apache Subversion a six out of ten only because it does not offer any latest features.

The positive impact of AWS CodeCommit on my organization was significant, especially transitioning from Subversion (SVN), which was an outdated technology for repositories. It was a very hectic process to pull or push code in SVN due to too many rules.

Before using AWS CodeCommit, I utilized GitHub and SVN for these use cases.

The most valuable features of AWS CodeCommit include the least privilege access from IAM, where permissions are granted only for the specific repository the developer is working on, which allows for hundreds of repositories with controlled access per project. Additionally, we can connect a domain to the repositories for easier access via a web browser, and the integration with CodePipeline, CodeBuild, and CodeDeploy allows for seamless pulling from the repository, building and deploying products. Furthermore, there are connections to GitHub for those who use external repositories, and notification rules for commits and deployments keep the team informed through emails or Microsoft Teams, making it very helpful for any organization.

The branch management and pull requests structure helped improve collaboration among my team by establishing an organized hierarchy where the tech lead, as the main interactant with developers, has the full admin policy for PR approvals. Developers test in the dev environment and raise a PR which the tech lead can approve if the code is acceptable, merging it into the main or current branch for release. Before going to the main branch, the developer branch has a testing phase where it's vetted by the QA team according to company rules. Once QA approval is received, the tech lead merges the code into the main branch for release, whether it's small, mini, or major.

Understanding AWS CodeCommit was a hectic job for developers at first, while it was easier for the DevOps team. Even with access, they faced questions and difficulties navigating the service, indicating a need for better documentation. It would be beneficial if users knew how to navigate the documentation to get assistance. Furthermore, AWS CodeCommit has been discontinued, so those who created repositories before its discontinuation retain full access, while those who lost access should be assisted by AWS in connecting to GitHub or alternative solutions for easier migration. Although AWS services integrate more seamlessly, connecting third-party tools to AWS CodeCommit can be challenging, emphasizing the need for improved integration processes.

The distinct issue I wanted to improve while working with AWS CodeCommit related to the migration process. Moving from legacy repository services like SVN to AWS should ideally include a reliable migration plan to attract users rather than forcing them to seek other services. The migration was quite hectic initially, taking around two weeks. Easier integration and migration tools would have addressed these challenges and eliminated the issues with AWS CodeCommit.

I have been working with AWS CodeCommit for about one and a half years now.

The decision to switch from previous solutions like SVN and GitHub was made by our DevOps lead. Understanding the issues with SVN, which was old and likely to close, the transition was needed due to the cumbersome process of pushing and pulling code that involved many steps. While SVN required substantial setup and multiple commands to manage a simple task, AWS CodeCommit utilizes cloud technology, making it significantly easier to handle everything from authentication to repository management in a more streamlined fashion.

I have been exploring AWS WAF, VPC subnets, and Lambda lately.

I worked with AWS CodeCommit about six months ago, or maybe more.

The integration of AWS Identity and Access Management and AWS CodeCommit for managing access control was initially quite hard as I had to navigate various groups including developers, QA teams, admin teams, and the main AWS admin controller while also developing with Terraform. Once I established IAM groups, it became viable to manage permissions based on user groups rather than attaching policies to individual users, simplifying access control as users only receive permissions associated with their respective group like dev, QA, or tech leads, which streamlined the organizational structure while also focusing on specific repository access.

On a scale of 1-10, I rate AWS CodeCommit a 9.