Skip to main content

Version control and outside contributors

The version control system your project uses can have a big impact on how easy it is for outside contributors to help out.

Svn (and cvs) make it difficult to contribute

Most projects restrict new or minor contributors to read only permission on their code repositories. This is common both for security and for organizational purposes, project maintainers often like to review changes before they go into mainline code. Read only access has its downside for contributors. If someone like myself wanted to contribute to a project that used svn the flow wold look something like:

- svn checkout
- Edit files in my editor
- Test
- svn diff > changes.patch
- Email/post changes to maintainer
- Wait until the changes are approved or rejected and checked in to svn
- Repeat starting at 'Edit files in my editor'

The bottleneck here is waiting for changes to be checked into svn. What if there were several changes in series? How would I be able to continue working on the next change if one change was already pending? What if the project maintainer(s) took a week to approve/reject or check in the changes?

Svn's centralized design is extremely constraining to rapid development and experimentation.

Making things easier with decentralized version control

Git and other decentralized version control systems solve the issues mentioned above. Git, for instance, enables users to check in any number of changes as well as create branches freely.

What if you want to use git but the project you'd like to contribute to is using svn? Github is a great resource that can help. They provide free hosting and have a helpful page about how to import a svn project into git.

Recently I wanted to start contributing to EmbSysRegView but the project is still using svn. I've been using git for several years now and at my full-time job for a year or two since I was able to convince the team to migrate from svn. I'd prefer to work in git because I could make several changes without having to wait for the maintainers. Plus git is a much faster tool.

It might be possible to convince the maintainer(s) to switch to git but this can be a bit of a learning process for them and other contributors. It turns out that patch files from git commits can be made compatible with svn in most cases. Git also has support for interacting with svn repositories natively. You can both import changes from svn as they are made and push changes back to svn repositories from git commits.

I decided to go this route and use github to host an import of the EmbSysRegView svn project. It took a few minutes but I was able to import the entire project including its history, tags etc, into a github project.


EmbSysRegView on github
Now that the project is in git it should be easy for me to make a series of changes, submit them as patches to the EmbSysRegView maintainers, and easily rewrite patches from their feedback.



Comments

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr...

Travelling on Spirit airlines out of Boston Logan airport? Here are some tips.

I attended CES 2017 in Las Vegas. Booking the trip late I ended up on Spirit airlines. It was both non-stop, making it six hours to Las Vegas from Boston, and affordable, less than $300 for a one way trip compared to around $700 with JetBlue. Here are some tips that might help you when travelling on Spirit from Boston Logan airport. Eat Spirit is located in the B-terminal, gates B-37 and 38, with its own TSA security checkpoint. While it does have restrooms and places to sit the food selection is limited to a single food stand. I'd recommend eating at the Legal C Bar (number 77 in the image below) prior to going through the terminal security checkpoint. The food and service there were great. Drink The water and other drinks are cheaper if you buy them at the food cart rather than on the flight. Seats The seats on Spirit don't recline. They do this to reduce weight, seat cost, seat maintenance costs, and so seats don't impact the free space of other passengers,...

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...