I started to use John's git mirror, and it convinced me of the advantages of git over subversion.

However, I still need to use svn for gramps-addons and for setting properties of files.  I don't know how git-svn handles svn branches, so I used svn to create the branch for the hierarchical places prototype.  I also met the mirror lag problems Vassilii mentioned.

For developers who make bigger changes, git would be a great help.  A simple step-by-step guide should avoid problems for new contributors, and non-developers such as translators.

Please can we convert to using git?

Perhaps we could start by converting the gramps-addons repository?



On 25/10/13 13:05, Benny Malengier wrote:
2013/10/25 Gerald Britton <>

1.8 svn has greatly simplified merges and I think addresses the main issues.  Also, I hear that git doesn't track moves very well, one of svn's strengths.

Subversion is not good for distributed development as is common in current OSS development.
A small example: We have to give everybody access to all code, also translators. With git, they only need to fork and do a pull request

I'm sure there are always solution for svn, but the core problem: it's design principle of a central repo, does not hold up for OSS.


On Oct 25, 2013 3:56 AM, "Vassilii Khachaturov" <> wrote:
On 25.10.2013 10:31, Benny Malengier wrote:

2013/10/25 Vassilii Khachaturov <>
On 24.10.2013 23:24, Benny Malengier wrote:
> It would seem ubuntu one is not able to sync all hidden .svn files.
> Or  because it is not fast enough, or because it chokes on the long
> filename.
> A better approach to your problems would be to fork the github gramps:
> You can then push and commit to your fork, and access that on all your
> computers, AND have local commits on your pc. Really superior to svn
> (though I myself for Gramps am still sticking to svn)
I've found my productivity significantly increase since the svn->git
transition, mainly because the cross-branch hops and merges are so much
quicker and easier now...
How about we switch to git after the coming release?

This discussion has been had already in the past. Some things:

1. We want to stick to sourceforge, so
This because sourceforge has been a good steward through the years.

Looks like things got better recently:

Also, it feels like sf is generally steering towards git as the main scenario. Their docs and screenshots  now have git as the primary choice (see for instance). So if we want to follow their stewardship, it feels like we should switch! :-)

2. We are afraid non programmers will have difficulties with git as opposed to svn. So translators, new contributors.
Absolutely agreed. We must provide full support to translators and new contributors, and ensure our wiki docs are up-to-date when we switch.
If we switch, I promise to give such support a priority. Probably we should get back to irc hangouts during the transition time...
Here's an example of another sf project's transition guide:

3. The git mirror of John is up and running for those who want git now

It's very good for read-only scenario, but its problem is that sometime you get into "Transaction out of date" git-svn hell trying to dcommit when multiple people commit on multiple branches and the mirror hasn't yet picked everything up. Still, it's so much better than SVN that I am not going back.
Personally I would like to switch. But I don't know if sourceforge git is good, I don't know how difficul it would be, and I don't know how easy non-programmers would have it.

The basic scenario (check-out, work, check-in) is all the same everywhere anyhow... We'll just have to update the procedures.

The really difficult unknown here is which is going to be more reliable as a service, sf SVN or sf git. But it feels like it will only get better with git with time. I did a reality check with google(sourceforge git support sucks), and I am not afraid :-)

The sf attitude about the conversion seems helpful and reassuring, see their response in , so I propose we go along this route (try to convert, see if it looks good, then switch) after the release...