From: Enno B. <enn...@gm...> - 2013-10-24 10:55:51
|
Yesterday, I added my gramps 3.4 svn directory to Ubuntu One, so that I can do some development on my desktop PC and laptop, which I am using right now. I have no commit rights, so I only use SVN to download updates, and compare my own hacks to what's in the repository. The code that was downloaded from Ubuntu One to my laptop builds OK, but when I try svn diff, I get an error message: svn: E000002: Can't open file '/home/enno/gramps34/.svn/pristine/76/76e7843e9616a1bb6932de1d9d408c501a882f43.svn-base': No such file or directory I'm not sure what it means, and running svn diff from other directories works, but I am a bit suspicious, because I'm not sure whether Ubuntu One syncs file removals too. If it does not, I suspect that my svn directory will become polluted after a while. Would svn cleanup help in this case? I'm quite new to SVN and Ubuntu One, so don't know what to do, except going back to a local backup when SVN or I get too confused. thanks, Enno |
From: Benny M. <ben...@gm...> - 2013-10-24 20:24:56
|
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: https://github.com/jralls/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) Benny 2013/10/24 Enno Borgsteede <enn...@gm...> > Yesterday, I added my gramps 3.4 svn directory to Ubuntu One, so that I > can do some development on my desktop PC and laptop, which I am using > right now. I have no commit rights, so I only use SVN to download > updates, and compare my own hacks to what's in the repository. > > The code that was downloaded from Ubuntu One to my laptop builds OK, but > when I try svn diff, I get an error message: > > svn: E000002: Can't open file > > '/home/enno/gramps34/.svn/pristine/76/76e7843e9616a1bb6932de1d9d408c501a882f43.svn-base': > No such file or directory > > I'm not sure what it means, and running svn diff from other directories > works, but I am a bit suspicious, because I'm not sure whether Ubuntu > One syncs file removals too. If it does not, I suspect that my svn > directory will become polluted after a while. > > Would svn cleanup help in this case? I'm quite new to SVN and Ubuntu > One, so don't know what to do, except going back to a local backup when > SVN or I get too confused. > > thanks, > > Enno > > > > ------------------------------------------------------------------------------ > 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 > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Vassilii K. <vas...@ta...> - 2013-10-25 06:17:45
|
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: > https://github.com/jralls/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? V |
From: Benny M. <ben...@gm...> - 2013-10-25 07:32:02
|
2013/10/25 Vassilii Khachaturov <vas...@ta...> > 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: > > https://github.com/jralls/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 http://sourceforge.net/p/forge/documentation/Git/ This because sourceforge has been a good steward through the years. 2. We are afraid non programmers will have difficulties with git as opposed to svn. So translators, new contributors. 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. Benny > > V > > > ------------------------------------------------------------------------------ > 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 > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Vassilii K. <vas...@ta...> - 2013-10-25 07:56:14
|
On 25.10.2013 10:31, Benny Malengier wrote: > > > > 2013/10/25 Vassilii Khachaturov <vas...@ta... > <mailto:vas...@ta...>> > > 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: > > https://github.com/jralls/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 > http://sourceforge.net/p/forge/documentation/Git/ > This because sourceforge has been a good steward through the years. > Looks like things got better recently: http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git 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! :-) > 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: http://sourceforge.net/apps/mediawiki/jabref/index.php?title=HOWTO_for_JabRef%27s_switch_from_Subversion_to_Git > > 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 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... V |
From: Gerald B. <ger...@gm...> - 2013-10-25 11:10:18
|
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 Oct 25, 2013 3:56 AM, "Vassilii Khachaturov" <vas...@ta...> wrote: > On 25.10.2013 10:31, Benny Malengier wrote: > > > > > 2013/10/25 Vassilii Khachaturov <vas...@ta...> > >> 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: >> > https://github.com/jralls/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 > http://sourceforge.net/p/forge/documentation/Git/ > This because sourceforge has been a good steward through the years. > > Looks like things got better recently: > > http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git > > 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! :-) > > 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: > > http://sourceforge.net/apps/mediawiki/jabref/index.php?title=HOWTO_for_JabRef%27s_switch_from_Subversion_to_Git > > > 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 > 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... > > V > > > > > ------------------------------------------------------------------------------ > 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 > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Benny M. <ben...@gm...> - 2013-10-25 12:05:14
|
2013/10/25 Gerald Britton <ger...@gm...> > 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. Benny > On Oct 25, 2013 3:56 AM, "Vassilii Khachaturov" <vas...@ta...> > wrote: > >> On 25.10.2013 10:31, Benny Malengier wrote: >> >> >> >> >> 2013/10/25 Vassilii Khachaturov <vas...@ta...> >> >>> 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: >>> > https://github.com/jralls/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 >> http://sourceforge.net/p/forge/documentation/Git/ >> This because sourceforge has been a good steward through the years. >> >> Looks like things got better recently: >> >> http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git >> >> 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! :-) >> >> 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: >> >> http://sourceforge.net/apps/mediawiki/jabref/index.php?title=HOWTO_for_JabRef%27s_switch_from_Subversion_to_Git >> >> >> 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 >> 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... >> >> V >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> |
From: Nick H. <nic...@ho...> - 2013-10-25 13:03:00
|
Benny, 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? Regards, Nick. On 25/10/13 13:05, Benny Malengier wrote: > 2013/10/25 Gerald Britton <ger...@gm... > <mailto:ger...@gm...>> > > 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. > > Benny > > On Oct 25, 2013 3:56 AM, "Vassilii Khachaturov" > <vas...@ta... <mailto:vas...@ta...>> wrote: > > On 25.10.2013 10:31, Benny Malengier wrote: >> >> >> >> 2013/10/25 Vassilii Khachaturov <vas...@ta... >> <mailto:vas...@ta...>> >> >> 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: >> > https://github.com/jralls/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 >> http://sourceforge.net/p/forge/documentation/Git/ >> This because sourceforge has been a good steward through the >> years. >> > Looks like things got better recently: > http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git > > 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! :-) > >> 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: > http://sourceforge.net/apps/mediawiki/jabref/index.php?title=HOWTO_for_JabRef%27s_switch_from_Subversion_to_Git >> >> 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 > 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... > > V > |
From: Doug B. <dou...@gm...> - 2013-10-25 13:12:18
|
On Fri, Oct 25, 2013 at 9:02 AM, Nick Hall <nic...@ho...> wrote: > Benny, > > 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? +1 > Perhaps we could start by converting the gramps-addons repository? That would be a fine start. Once we discuss a couple of other points: BTW, I really like the ability of interfaces like git + bitbucket to allow comments on entire commits, and also on lines of a commit. If sourceforge does not plan on adding that, then I would vote for moving to a system that does allow it. Bitbucket (and I suspect github) has some very nice support via the web for the social aspects of development. I would strongly recommend that we look at github/bitbucket/others before dismissing them too quickly. I've just learned git this year, and very much prefer it. I like stashing my changes. And being able to work offline for a bit, while I accumulate some commits. But I really love the web interface bitbucket provides. -Doug > Regards, > > > Nick. > > > > On 25/10/13 13:05, Benny Malengier wrote: > > 2013/10/25 Gerald Britton <ger...@gm...> >> >> 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. > > Benny >> >> On Oct 25, 2013 3:56 AM, "Vassilii Khachaturov" <vas...@ta...> >> wrote: >>> >>> On 25.10.2013 10:31, Benny Malengier wrote: >>> >>> >>> >>> >>> 2013/10/25 Vassilii Khachaturov <vas...@ta...> >>>> >>>> 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: >>>> > https://github.com/jralls/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 >>> http://sourceforge.net/p/forge/documentation/Git/ >>> This because sourceforge has been a good steward through the years. >>> >>> Looks like things got better recently: >>> >>> http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git >>> >>> 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! :-) >>> >>> 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: >>> >>> http://sourceforge.net/apps/mediawiki/jabref/index.php?title=HOWTO_for_JabRef%27s_switch_from_Subversion_to_Git >>> >>> >>> 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 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... >>> >>> V >>> > > > ------------------------------------------------------------------------------ > 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 > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Paul F. <pf....@gm...> - 2013-10-25 16:21:44
|
It saddens me to see this discussion happening again. While I respect git-philes and their opinion I somewhat don't like the way some keep pushing to have it their way. There are drawbacks to using git now which they are happy not to mention whenever they suggest it again. But one of the main ones is what sort of a group of people does gramps want, for its developers. Many of the people commenting on this thread so far seem to me to be professional programmers. Some even have their doctorates and work at universities. Fine, but if you want to restrict gramps development to such people you should say so, make that decision. I have no doubt that professional programmers are a lot more flexible with regards to learning new tools to help them do their work. After all, that's their job, that's the career they chose, that's the skill set they have. If those are the only type of people you want, then say so. I vote against git -- not that I am under any illusions as to what my vote counts for in such matters. |
From: Doug B. <dou...@gm...> - 2013-10-25 16:37:53
|
On Fri, Oct 25, 2013 at 12:21 PM, Paul Franklin <pf....@gm...> wrote: > It saddens me to see this discussion happening again. > > While I respect git-philes and their opinion I somewhat > don't like the way some keep pushing to have it their way. > > There are drawbacks to using git now which they are > happy not to mention whenever they suggest it again. > > But one of the main ones is what sort of a group of > people does gramps want, for its developers. Many of > the people commenting on this thread so far seem to > me to be professional programmers. Some even have > their doctorates and work at universities. > > Fine, but if you want to restrict gramps development to > such people you should say so, make that decision. > > I have no doubt that professional programmers are a lot > more flexible with regards to learning new tools to help > them do their work. After all, that's their job, that's the > career they chose, that's the skill set they have. > > If those are the only type of people you want, then say so. > > I vote against git -- not that I am under any illusions as to > what my vote counts for in such matters. Hey, Paul, don't feel sad, or dejected! We'll probably keep having this same conversation forever... it is the nature of continued development. It is not a foregone conclusion that we'll ever change to a new tool, but for those of us that do this a lot, having a good tool makes a big difference. But having a good tool doesn't necessarily mean that it won't also be good for the rest of the community. For example, I see that some git hosts also allow editing files directly on the website. To me, that shows that not only is git a new, sophisticated tool, but it allows (or inspires) people to create new ways of doing things. This is really exciting to be able to make the interactions more accessible. So, I'm with you: if it makes it hard for regular humans to contribute, don't do it. But, if it allows new ways that are better, then we have to do it! BTW, I don't find git to be any harder for basic use than svn --- just different. In fact the Windows client I have used makes it easier. -Doug > ------------------------------------------------------------------------------ > 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 > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Nick H. <nic...@ho...> - 2013-10-25 18:01:29
|
On 25/10/13 17:37, Doug Blank wrote: > For example, I see that some git hosts also allow editing files > directly on the website. To me, that shows that not only is git a new, > sophisticated tool, but it allows (or inspires) people to create new > ways of doing things. This is really exciting to be able to make the > interactions more accessible. > > So, I'm with you: if it makes it hard for regular humans to > contribute, don't do it. But, if it allows new ways that are better, > then we have to do it! I agree. We need something that is easy to use for translators and other members of the community without much programming experience. A good web interface might be useful for them. > > BTW, I don't find git to be any harder for basic use than svn --- just > different. In fact the Windows client I have used makes it easier. Basic use of git is really very simple. The only extra step is that once committed locally, a change must be pushed to the repository. Many people will never use the more advanced features, but they are very useful for experienced developers. Nick. |
From: Harmen H. <har...@si...> - 2013-10-29 13:03:05
|
As I'm a translator of Gramps just my ideas. I don't know the real differences between the two version control systems. At this moment I send my changes in the Dutch translation to Erik and he commits it with svn. Every now and then I do an svn up to get the latest version of Gramps. If there is an equivalent command in git I don't care. However, I really like the idea of translating Gramps with a webinterface, like launchpad but there are others that do the same thing. Everyone can make a suggestion on the website and the regular translators can accept or reject the translation suggestion. I don't know if this has something to do with (selecting) a version control, but maybe this could be taken into consideration. Harmen 2013/10/25 Nick Hall <nic...@ho...> > On 25/10/13 17:37, Doug Blank wrote: > > For example, I see that some git hosts also allow editing files > > directly on the website. To me, that shows that not only is git a new, > > sophisticated tool, but it allows (or inspires) people to create new > > ways of doing things. This is really exciting to be able to make the > > interactions more accessible. > > > > So, I'm with you: if it makes it hard for regular humans to > > contribute, don't do it. But, if it allows new ways that are better, > > then we have to do it! > > I agree. We need something that is easy to use for translators and > other members of the community without much programming experience. A > good web interface might be useful for them. > > > > > BTW, I don't find git to be any harder for basic use than svn --- just > > different. In fact the Windows client I have used makes it easier. > > Basic use of git is really very simple. The only extra step is that > once committed locally, a change must be pushed to the repository. > > Many people will never use the more advanced features, but they are very > useful for experienced developers. > > Nick. > > > > ------------------------------------------------------------------------------ > 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 > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Luigi T. <lui...@ti...> - 2013-10-29 13:24:19
|
Harmen Huizinga wrote: > As I'm a translator of Gramps just my ideas. I don't know the real differences > between the two version control systems. At this moment I send my changes in > the Dutch translation to Erik and he commits it with svn. Every now and then I > do an svn up to get the latest version of Gramps. If there is an equivalent > command in git I don't care. > > However, I really like the idea of translating Gramps with a webinterface, > like launchpad but there are others that do the same thing. Everyone can make > a suggestion on the website and the regular translators can accept or reject > the translation suggestion. I don't know if this has something to do with > (selecting) a version control, but maybe this could be taken into consideration. Hi all, I'm the Italian translator (a bit behind the current translation status, but still over 90% :) Personally speaking I have no problems with git (as a programmer). That said, the KDE translator community I contribute too, decided to keep translations on SVN even if the programs migrated to git, because many translators are not technical people and git easily allows you to shot yourself in the foot. Web translations: as long as it is possible to ignore them and use offline tools I'm fine. I prefer offline tools, which I find more flexible and powerful (see http://pology.nedohodnik.net/) and do not force you to stay online while translating. Ciao -- Luigi |
From: Nick H. <nic...@ho...> - 2013-10-29 16:53:38
|
On 29/10/13 12:40, Harmen Huizinga wrote: > As I'm a translator of Gramps just my ideas. I don't know the real > differences between the two version control systems. At this moment I > send my changes in the Dutch translation to Erik and he commits it > with svn. Every now and then I do an svn up to get the latest version > of Gramps. If there is an equivalent command in git I don't care. Yes, there are equivalent commands in git. Instead of "svn checkout <url>" you would use "git clone <url>". To get the latest changes you would use "git pull" rather than "svn update". With git your commits are local, so you have to push them to the repository. So "svn commit" becomes "git commit -a" followed by a "git push". Some commands such as "git status", "git log", "git blame" and "git diff" will be familiar to subversion users. Nick. |
From: Luigi T. <lui...@ti...> - 2013-10-29 17:06:09
|
Nick Hall wrote: > On 29/10/13 12:40, Harmen Huizinga wrote: >> As I'm a translator of Gramps just my ideas. I don't know the real >> differences between the two version control systems. At this moment I >> send my changes in the Dutch translation to Erik and he commits it >> with svn. Every now and then I do an svn up to get the latest version >> of Gramps. If there is an equivalent command in git I don't care. > > Yes, there are equivalent commands in git. Instead of "svn checkout > <url>" you would use "git clone <url>". To get the latest changes you > would use "git pull" rather than "svn update". > > With git your commits are local, so you have to push them to the > repository. So "svn commit" becomes "git commit -a" followed by a "git > push". But please consider that if you don't want to mess up with the history and create some useless merge commits you have to learn a bit about rebasing (which is the complicated part). Ciao -- Luigi |
From: Paul F. <pf....@gm...> - 2013-10-25 18:02:25
|
On 10/25/13, Doug Blank <dou...@gm...> wrote: > It is not a foregone conclusion that we'll ever change to a new tool, > but for those of us that do this a lot, having a good tool makes a big > difference. For those of us who /don't/ "do this a lot" having the /same/ tool makes a big difference. 8-) > But having a good tool doesn't necessarily mean that it won't also be > good for the rest of the community. Maybe, once /everybody/ in the "community" has gone through the same learning curve the git-users have done. > So, I'm with you: if it makes it hard for regular humans to > contribute, don't do it. But, if it allows new ways that are better, > then we have to do it! We don't "have to do" anything. If git allows more efficient use of a developer's time then those developers who choose that can use git right now -- as I understand it. > BTW, I don't find git to be any harder for basic use than svn --- just > different. In fact the Windows client I have used makes it easier. The point is not the relative ease of use of git vs. svn. The point is whether you want every contributor to be forced to learn a new way. It seems to me there were quite a few problems when we switched over to the new SourceForge repo. It seems to me they were all unanticipated. Why not rewrite gramps in Java (or whatever it takes to be able to run it on a tablet)? I'm sure all of you who know Java wouldn't have any problems what that. Why not rewrite gramps in C++ or whatever would make it blindingly fast? I'm sure all of you who know C++ wouldn't have any problems with that. I still vote against git. |
From: Benny M. <ben...@gm...> - 2013-10-29 09:31:23
|
2013/10/25 Paul Franklin <pf....@gm...> > On 10/25/13, Doug Blank <dou...@gm...> wrote: > > It is not a foregone conclusion that we'll ever change to a new tool, > > but for those of us that do this a lot, having a good tool makes a big > > difference. > > For those of us who /don't/ "do this a lot" having the /same/ > tool makes a big difference. 8-) > > > But having a good tool doesn't necessarily mean that it won't also be > > good for the rest of the community. > > Maybe, once /everybody/ in the "community" has gone > through the same learning curve the git-users have done. > > > So, I'm with you: if it makes it hard for regular humans to > > contribute, don't do it. But, if it allows new ways that are better, > > then we have to do it! > > We don't "have to do" anything. If git allows more efficient > use of a developer's time then those developers who choose > that can use git right now -- as I understand it. > > > BTW, I don't find git to be any harder for basic use than svn --- just > > different. In fact the Windows client I have used makes it easier. > > The point is not the relative ease of use of git vs. svn. > The point is whether you want every contributor to be > forced to learn a new way. > > It seems to me there were quite a few problems when we > switched over to the new SourceForge repo. It seems to > me they were all unanticipated. > > Why not rewrite gramps in Java (or whatever it takes to > be able to run it on a tablet)? I'm sure all of you who know > Java wouldn't have any problems what that. > > Why not rewrite gramps in C++ or whatever would make it > blindingly fast? I'm sure all of you who know C++ wouldn't > have any problems with that. > > I still vote against git. > And I vote for the future :-). Of the last 5 programs I needed to install manually on my pc, all 5 used git. So soon, only the dinosaurs will still know svn. Anyway, an example of git on sourceforge: https://sourceforge.net/p/cdk/code/ci/master/tree/ Seems not the nice interface of github, gitorious or bitbucket. Many projects on sourceforge seem to use sourceforge only for file distribution on release, not anymore for code hosting. An option. I would suggest somebody sets up an online poll to ask developers what they would vote for: 1. keep svn 2. git on sourceforge 3. git, need not be on sourceforge Voting with your subversion login (so eg bmcage for me). We'll see how the cards fall then. Next, if git clear majority, find somebody to investigate best option, and then actually do the transition. Benny |
From: Paul F. <pf....@gm...> - 2013-10-29 14:41:35
|
You "online poll" seems to me to ignore the fact that we have SVN committers who are only active once a year and probably don't read the gramps-devel list at all. If you just post a notice to vote on gramps-devel you will bias the result in the favor of the active-at-the-moment developers, probably 90% of which are the professional programmers I mentioned. Because they know and use git they will have no problem voting for it. They will not be considering the "big picture" at all. And the gramps translators and non-expert developers out there. Second, your desire to put git to a vote seems to me to totally ignore the fact that git users and lovers can use the git bridge that John set up right now. What's wrong with continuing with that, as it is? If we go to git who's going to set up a bridge the other way, so that SVN users can continue to pull from it and /also/ upload to it? Third, in another thread you expressed a distaste for bureaucracy. I have a similar distaste but I also have a distaste for people (not you) who try to impose their viewpoint on others. There are some people in America who feel that the convictions they believe in, typically from their religious views, are so obviously correct and right and true that /everybody/ should be /forced/ to follow them too. There are some people in Muslim countries who feel the same. In a democracy I think the majority should respect any minority and not /force/ them to do whatever the majority wants. Even if the majority "votes" on it. On the other hand, perhaps you'll say that the gramps community is not a democracy. If so, that will be two reasons you will probably see very little of me afterwards. Respectfully. |
From: Nick H. <nic...@ho...> - 2013-10-29 17:38:14
|
On 29/10/13 14:41, Paul Franklin wrote: > You "online poll" seems to me to ignore the fact that we have > SVN committers who are only active once a year and probably > don't read the gramps-devel list at all. If you just post a notice > to vote on gramps-devel you will bias the result in the favor of > the active-at-the-moment developers, probably 90% of which > are the professional programmers I mentioned. Because they > know and use git they will have no problem voting for it. They > will not be considering the "big picture" at all. And the gramps > translators and non-expert developers out there. Since 1 Oct 2012 there have been 22 committers. We should try to get the opinions of all of them. > > Second, your desire to put git to a vote seems to me to totally > ignore the fact that git users and lovers can use the git bridge > that John set up right now. What's wrong with continuing with > that, as it is? If we go to git who's going to set up a bridge the > other way, so that SVN users can continue to pull from it and > /also/ upload to it? The git mirror is usable but has issues. I don't have a problem with continuing to use svn, but if there is a tool available that makes life easier, I would prefer to use it. If we move to git there will be no svn mirror. I'll create a post to send to the list. Lets see how many people reply. Nick. |
From: Benny M. <ben...@gm...> - 2013-10-31 14:19:07
|
2013/10/29 Paul Franklin <pf....@gm...> > You "online poll" seems to me to ignore the fact that we have > SVN committers who are only active once a year and probably > don't read the gramps-devel list at all. If you just post a notice > to vote on gramps-devel you will bias the result in the favor of > the active-at-the-moment developers, probably 90% of which > are the professional programmers I mentioned. Because they > know and use git they will have no problem voting for it. They > will not be considering the "big picture" at all. And the gramps > translators and non-expert developers out there. > > Second, your desire to put git to a vote seems to me to totally > ignore the fact that git users and lovers can use the git bridge > that John set up right now. What's wrong with continuing with > that, as it is? If we go to git who's going to set up a bridge the > other way, so that SVN users can continue to pull from it and > /also/ upload to it? > > Third, in another thread you expressed a distaste for bureaucracy. > I have a similar distaste but I also have a distaste for people (not > you) who try to impose their viewpoint on others. There are some > people in America who feel that the convictions they believe in, > typically from their religious views, are so obviously correct and > right and true that /everybody/ should be /forced/ to follow them > too. There are some people in Muslim countries who feel the same. > > In a democracy I think the majority should respect any minority and > not /force/ them to do whatever the majority wants. Even if the majority > "votes" on it. On the other hand, perhaps you'll say that the gramps > community is not a democracy. If so, that will be two reasons you > will probably see very little of me afterwards. > Hey! This is exactly my beef with many people who claim to be democratic. They believe once their view has the majority, all should follow. No matter how much I try to explain democracy should not be interpreted like that, I can't convince them. But those discussion should go on some other forum, not the gramps devel list :-) To reply. 1/ If all core developers use the svn to git bridge, then git should be the official way. Too many things will start to happen outside of the official repo, with no history visible in the official repo. That is bad, and we should avoid it at all cost! Think eg a gep branch. Eg, nick already indicated squashing commits. He does that outside of the main repo. For a larger feature implementation, I would find that highly annoying. I would need to be able to rely on finding Nicks git fork, hope the branch is around, and go through history there, to see if I can understand why a change was done. It's better if development was in a branch of the official repo which Nick forked, and squashing commits only happens to merge in trunk. 2/Brian and me have been wanting to clean out the commit list. Too many people have commit rights of who we don't even know who they are. The plan was to remove everybody and then readd based on them asking. This has been discussed by me and Brian off-list some time ago. This can coincide with git move, or should be done anyway in the near future. If Nick says 22 commiters last year, those are good start. 3/Unfortunately, though we want some form of compromise decisions, OSS development is indeed traditionally not a democracy. I hope you don't run away now! The admin of Gramps eg have not been voted for, they were appointed by a previous admin (which could be another discussion for the future). It all resembles more a 'rule by committee' to me. I don't mind changing things, but Gramps does not have the financial mussle to go to a foundation or other form of official structure. Anyway, to go back to the democracy statement of the start, yes minorities need to be protected, but on the other hand, the minority may not block the majority. They _need_ to allow discussion on how the exasperations of the majority can be alleviated, without stepping on their rights. Us Belgians are very aware of this :-) Current emails are that discussion. Benny |
From: Nick H. <nic...@ho...> - 2013-11-01 10:34:07
|
On 31/10/13 14:18, Benny Malengier wrote: > 1/ If all core developers use the svn to git bridge, then git should > be the official way. More and more developers will start using git when they see the power of it. > Too many things will start to happen outside of the official repo, > with no history visible in the official repo. That is bad, and we > should avoid it at all cost! Think eg a gep branch. Eg, nick already > indicated squashing commits. He does that outside of the main repo. Yes. I try to avoid svn branches unless I have to use them. The result is large patches which lack history. > For a larger feature implementation, I would find that highly > annoying. I would need to be able to rely on finding Nicks git fork, > hope the branch is around, and go through history there, to see if I > can understand why a change was done. I don't push my work to a public git repository. > It's better if development was in a branch of the official repo which > Nick forked, and squashing commits only happens to merge in trunk. > I agree, and git branches are a good way to handle this. Nick. |
From: John R. <jr...@ce...> - 2013-10-25 14:32:55
|
On Oct 25, 2013, at 5:05 AM, Benny Malengier <ben...@gm...> wrote: > > > > 2013/10/25 Gerald Britton <ger...@gm...> > 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. Everybody has access to all of the code, independent of what VCS we use. That's what Open Source is all about. There's no difference between submitting patches and sending pull requests, except that both are much easier in git. So is properly crediting authors, because git tracks both where svn doesn't (or didn't, I haven't looked at 1.8). The real benefit of git over svn is the ability to have a private branch in which to separate big jobs from the mainline code until they're ready to merge, and the ability to merge a chunk of work and keep working in the branch to merge more later -- though I understand that svn can also do that since 1.7. Regards, John Ralls |
From: John R. <jr...@ce...> - 2013-10-25 14:32:26
|
On Oct 25, 2013, at 4:10 AM, Gerald Britton <ger...@gm...> wrote: > 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. That's nice, but SourceForge doesn't use svn 1.8, it uses 1.6. See http://sourceforge.net/p/forge/documentation/svn/ . Git handles moves very nicely, thank you. See https://github.com/jralls/Gramps/commit/e3b880841a2c56942d4b0b73accf9c97d595a755 for Benny's massive move from src to gramps, and compare it with https://sourceforge.net/p/gramps/code/20466/ . Regards, John Ralls |
From: Enno B. <enn...@gm...> - 2013-10-25 10:41:14
|
On 24-10-13 22: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. Maybe so. I switched to a USB backup, and that's OK. > A better approach to your problems would be to fork the github gramps: > https://github.com/jralls/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'll stick to that too, because I'm a conservative, and know the differences between my files and the main repository. Forking on GIT would probably confuse me more than it would help. thanks, Enno |