Proposal for migration from Subversion to Git.

[Christian Stimming]

Dear Tao,

I'm all in for this. We might consider such changes right after the 2.4.0 
release, but that isn't too far away, so discussing it now is fine. Thanks for 
the suggestion. IMHO git gives a significant amount of benefit over SVN, 
simply because the versioning system doesn't enforce any sort of development 
process, but instead the versioning system can adapt to that process which 
fits best.

And also, as you said, git is much much much faster than SVN. If I had the 
choice, I would use git completely ASAP and get rid of SVN altogether.

However, currently the setup of the SVN server also implies a particular 
development process, namely the "single-trunk" process by some core group with 
repository write access. That core group (currently 10-15 developers) commit 
all to one single branch ("trunk"), so that "trunk" is always the branch where 
all changes are integrated. If there are contributions from others, someone 
from the core group needs to commit and also do some initial checking (like, 
checking whether the compile isn't broken).

How would this development process be mapped into git? I know every developer 
can have his/her own master branch in the repo, but how would projects usually 
decide which parts go into the master-master branch?

I think it would be good to have some test setup of the gnucash code base in 
git somewhere, and see how well the current development process can be 
implemented there - and what  improvements will be possible as well. Do you 
think you can demonstrate such a test setup somewhere? The code base is there, 
you only have to copy it somewhere online.

Best Regards,

Christian



Am Saturday 07 August 2010 schrieb Tao Wang:
> Hi, guys,
> 
> I tried Git these days for development. It looks great. So, I suggest we
> migrate our repository from Subversion to Git.
> 
> I prefer move to Git for following reasons:
> 
> 1) Git is really fast, especially when you want to check annotates, history
> log or past modifications.
> 
> 2) Git is able to do the offline commit, so you don't need to have an
> internet connection for development. For Subversion, everytime you do the
> 'svn commit', 'svn log', you have to be online. It matters if you don't
> have internet access currently, and you need several commits for different
> tasks, and definitely you don't want to mix them up to make it hard to
> revert. Git can do that easily.
> 
> 3) Git can create local branch very easy, without interacting with online
> repository. So, if you have any idea and don't want to interrupt current
> branch, just create a local branch, if it's working, then just rebase to
> the branch you are working on and push back to online repository later, if
> it's not as you thought, just drop it. Local branches will not affect the
> online repository.
> 
> 4) Surprisingly, Git repository is smaller than Subversion, even it's hold
> entire history of commits locally. So, do a fresh 'git clone' is much
> faster than 'svn checkout'.
> 
> Something we also need to be noticed is that:
> 
> 1) There is no revision number in Git, instead, it's a long not very
> human-readable SHA1 hash code for each revision.
> 2) I'm not sure how Git handle new line, it looks no equivalent
> svn:eol-style=LF.
> 
> Any ideas?