This project is read-only.

Thoughts on our source control

Jul 16, 2008 at 3:35 PM
There have been some murmoring about our source control setup, mainly that merging into the mainline is difficult. What are everyones opinions on our setup? How would you improve it?

Our process currently consists of three parts, Jeff's github repository, Developer's github repository, and Developer's local repository. This means Jeff is responsible for pulling changes from each developer's github account once a Developer has pushed their changes, and merging them into the mainline. This is putting the responsibility of maintaining the mainline soely on Jeff.

Personally, I'm enjoying working with git and github, but I do think our process is limiting our pace. An option would be to move away from Jeff's github account to a central BooLangStudio account. All major committers* would have access to this repository, and could do their own merging. Our process could either remain the same, but with each developer able to merge their own changes into the mainline, or we could work directly off the central repository. That's one possibility.

We have to consider that git, by nature, is a distributed source control system, it isn't specifically designed to work around a central repository. I think we're all used to working in a centralised model, so it may be that we're trying to bend git to how we expect to work.

As Jeff mentioned in one of the other threads, we've been doing a lot of big stuff separately from each-other, mainly because we didn't have much to begin with. It may be the case that once we get over this hump and get everything merged, that things may become easier anyway. I think we definately need to see this through before we make any big changes.

I've waffled a bit, sorry. I see our options for the future as:
  1. Stay as we are
  2. Stay with github, but improve our process
  3. Move to a Subversion host

What does everyone think?

* I say major committers, but that's all of us right now ;)
Jul 17, 2008 at 12:17 PM
I have been reading up on git and I seems like all projects have a central git repository (or more than one) where multiple team members can push changes to. A common practice in big projects seems to be that each sub-team have their own central repository where they push changes to, and then one or more integrators can push those changes up to the main repository.

The problem with the current setup is that we only have one "integrator" with commit access to the main repository (currently Jeffery's). I think if we (Justin, Me, Jeffery and James) all had commit access to a main repository we could work quicker as we could directly test and work with each others changes. And if new developers forked the main repository and did something good we would have 4 people with the possibility to review and merge those changes into the main repository, and if that developer kept on doing good work we could grant him commit access as well. I think git is not about completely decentralized vs completely centralized, it's about having the opportunity to mix the two. And personally I do not think that git's main strength compared to Subversion is its decentralized nature but its support for proper merging.

So I would be happy staying with git, granted we switched to a more centralized way of working (for the core developers), I would be happy with a move to Subversion as well as I like TortoiseSVN so much, but learning git is fun even though it is a little user unfriendly.

An argument for switching to Subversion could be that we might limit the number of developers who could potently be interested in helping but don't because they find git/github to much of a hassle, I don't know, this might be a week argument :)

Linus Torvalds on git, and centralized repositories:
http://lwn.net/Articles/246381/


Jul 17, 2008 at 1:18 PM
That's a really good read you linked to, I was wondering how the kernel was setup.

I enjoy working with git and github, they're both new and interesting, different to what I use at work every day. I haven't had any problems with the client tools, and I'm quite content to work on the commandline. So my vote is for staying with git, but I agree we need to move to a more centralised setup.
An argument for switching to Subversion could be that we might limit the number of developers who could potently be interested in helping but don't because they find git/github to much of a hassle, I don't know, this might be a week argument :)
I'm not too concerned about this. There might be a minority that would be turned off, but I think anyone who seriously wants to help will be fine with using git. We all were, after all!
Jul 17, 2008 at 1:37 PM
I agree, that is why I think it was a weak argument :)
Jul 17, 2008 at 5:55 PM
One question, I know github is free up to a certain size. What is the likelihood of us maxing that size out and being required to pay for github?
Jul 18, 2008 at 1:52 AM


justinc wrote:
One question, I know github is free up to a certain size. What is the likelihood of us maxing that size out and being required to pay for github?


It looks pretty minimal in the near term actually. I have about .5MB out of 100MB used up currently, so that should last a while.