2013/10/25 Gerald Britton <email@example.com>
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" <firstname.lastname@example.org> wrote:
On 25.10.2013 10:31, Benny Malengier wrote:
Looks like things got better recently:
2013/10/25 Vassilii Khachaturov <email@example.com>
On 24.10.2013 23:24, Benny Malengier wrote:I've found my productivity significantly increase since the svn->git
> 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
> 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)
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 http://sourceforge.net/p/forge/documentation/Git/
This because sourceforge has been a good steward through the years.
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 http://sourceforge.net/create/ for instance). So if we want to follow their stewardship, it feels like we should switch! :-)
Absolutely agreed. We must provide full support to translators and new contributors, and ensure our wiki docs are up-to-date when we switch.2. We are afraid non programmers will have difficulties with git as opposed to svn. So translators, new contributors.
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:
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.
3. The git mirror of John is up and running for those who want git now
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 http://sourceforge.net/apps/trac/sourceforge/ticket/24534 , so I propose we go along this route (try to convert, see if it looks good, then switch) after the release...