There are many differences between git and svn which can be useful.
Of course, for the main repository you can't just hand out commit access to everyone, but
it is easy to create remote branches for whoever wants one.
You can even put them on the same server without wasting space.
If you `git clone --bare` from a local repository, git uses hardlinks so only the new changes
take up space on the HDD.
To get an idea of how things can be set up, just take a look at
http://git.kernel.org
And in one repo you can also make multiple branches. You can also make a remote repo on another
server of course.
But git makes it easy to sync a branch to the main branch.
For example, say there's the server x with a nexuiz.git repo, and you'd want to give fruitiex
a repository where he can work on his hud changes.
on x you could do:
- Code: Select all
cd /srv/git/nexuiz-branches
git clone --bare /srv/git/nexuiz.git fruitiex.git
Now, whoever has a checkout of nexuiz.git can pull from that new repository within seconds:
- Code: Select all
# add fruitiex' repo as a remote (once):
git remote add fruitiex http://x/nexuiz-branches/fruitiex.git
git fetch fruitiex
git branch --track hud-background fruitiex/hud-background
# switch to the hud branch
git checkout hud-background
# every so often just do
git pull
# (when on the fruitiex branch) to update
Since fruitiex.git is based on nexuiz.git the whole checkout just takes a few seconds.
You can easily test his additions and if you think they're good enough to be merged into the main
trunk you can do:
(assuming you're currently on the master branch, if not: git checkout master)
- Code: Select all
git merge master fruitiex/hud-background
git commit
git push
Also, if fruitiex has to resolve merging issues first he could do the merge the other way round first.
If fruitiex branch was on another remote server, nothing would be different (except the URL of course).
It also just takes some seconds.
Also, a git-svn mirror can work both ways.
On a remote server one can do:
- Code: Select all
git --bare init
git --bare svn init -s http://..../nexuiz
git config svn-remote.svn.fetch trunk:refs/remotes/master #only fetch the trunk and name it master locally - makes things easier
git --bare svn fetch
# setup the actual git mirror
git config remote.origin.url .
git config remote.origin.fetch +refs/remotes/tags/*:refs/tags/*
git config --add remote.origin.fetch +refs/remotes/*:refs/heads/*
# now `git --bare svn fetch` fetches from SVN and `git fetch` updates the git mirror to
# contain the actual SVN changes
git fetch
I actually tried that (one way) on a server, and it works pretty well
I haven't tried pushing back to the SVN server though
Should try that on another SVN repository I guess
So basically,
if there are enough people interested in coding it can be very useful, if not, it's a waste of time and disk space. (Or even if one person wants to maintain multiple branches with multiple features to test.)
But of course, you need to do a git checkout first to start working with it. So if you currently have an SVN checkout... switching is a PITA
since the first checkout of nexuiz always takes ages
This is just an information. Personally I'd like it if we were to use git, but for me patches to download, apply and maybe revert are fine too - mainly because git isn't the easiest thing to master anyway, so people have to get used to it first, too.
And a git-svn mirror works too - for quite some time.
Since I could just get a diff from the git-svn master to a branch and apply to the SVN code if I wanted to anyway.