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.
On 25.10.2013 10:31, Benny Malengier wrote:
Looks like things got better recently:
2013/10/25 Vassilii Khachaturov <firstname.lastname@example.org>
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...
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
Gramps-devel mailing list