Invirt Project

Switch Invirt to git

Registered by Evan Broder

Invirt should consider switching to git for SCM instead of svn. There are certainly all the standard reasons why git is better than svn (http://whygitisbetterthanx.com/#svn).

I think the real win, though, is when Invirt starts to be used outside of MIT. Until our software reaches the point where it is su utterly generic that anyone can use it without requiring patches to the repo, people like HCS would presumably like to be able to have their own first-class SCM repo where they can maintain whatever site-local patches were necessary.

I don't know what the resulting git structure should look like - whether it should have one repo per package or a single massive repo for everything. We'd also need to be sure to deal with package_tags and update our build tools.

I'm entering this as a Blueprint instead of a Bug because I don't think it's entirely clear that we should move to git, so I'd like to hear what other people think.

Blueprint information

Status:
Not started
Approver:
None
Priority:
High
Drafter:
None
Direction:
Approved
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

You know, I was going to identify which item on whygitisbetterthanx.com this fell under, but he really doesn't cover it. The point should be something like "Everyone can fork". It's definitely a major point for us as we get outside users, because we do still rely heavily on changing the code, particularly in the web interface.

We probably want a single repo. We've moved things around and split and recombined packages enough that it'd be a pain to have several.

-- Greg, 2008-12-11

If you try to put all the code in a single repo, you will hate yourself. Using one repo per package is the only thing that makes sense with the Git model. It’s important for having useful package tags, using git-buildpackage, pulling from upstream sources, and linking to the repo using debian/control’s Vcs-Git: header. Git repos aren’t painful to create like CVS and Subversion, and you can gain most of the benefit of a single repo by using Git submodules.

-- Anders, 2008-12-11

Greg pointed out that one repo per package loses us the ability to move files between packages (which we do do every once and a while, e.g. a bunch of files need to move from invirt-web to invirt-base). I assume that the response is something like "small price to pay for more sanity"?

-- Evan, 2008-12-12

Correct. If you anticipate the need to move files around between packages, one possible answer is that these packages should have been part of the same source package. Otherwise, yeah, you do the move manually.

-- Anders, 2008-12-12

geofft suggested using git submodules. When initializing git submodules, you can checkout a specific branch into the submodule.

What if we import each package as a branch in a single repository, and use submodules to checkout each branch into the master branch?

-- Evan, 2008-12-12

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.