From: Gaëtan A. <gae...@gm...> - 2013-10-29 08:18:07
|
Hi all, This mail follow the Xavier's mail on Release 2.1. We are currently using SVN which have major cons : 1/ Operations are slow, especially checkout. 2/ Branching is a headache 3/ Too centralise 4/ ... More in your replies. Alternatives : Git, Hg (Mercurrial) and Bzr (Bazaar). AFAIK (correct me if I am wrong) Git and Hg are more or less the same from a user point of view. I have never used Hg, but here are the pros of git : 1/Very fast operations 2/Easy local branching 3/Easy remote branching 4/Local commits 5/Decentralized 6/ ... More in your replies. What about git under Windows ? Is it working ? well ? As for Bzr, I don't know anything about it. Any comments ? I suggest we discuss the pros an cos of all of them for a week, and then, launch a vote . Cheers Gaëtan |
From: Xavier B. <ber...@ya...> - 2013-10-29 08:38:28
|
Hi Gaétan, On windows i'm using tortoisegit work vert well. For hg, personnaly i don't like more difficult for users ( do an updating And after do a pull) Cheers Xavier Envoyé de mon iPhone > Le 29 oct. 2013 à 09:17, Gaëtan André <gae...@gm...> a écrit : > > Hi all, > > This mail follow the Xavier's mail on Release 2.1. > > We are currently using SVN which have major cons : > 1/ Operations are slow, especially checkout. > 2/ Branching is a headache > 3/ Too centralise > 4/ ... > More in your replies. > > Alternatives : Git, Hg (Mercurrial) and Bzr (Bazaar). > > AFAIK (correct me if I am wrong) Git and Hg are more or less the same from a user point of view. I have never used Hg, but here are the pros of git : > 1/Very fast operations > 2/Easy local branching > 3/Easy remote branching > 4/Local commits > 5/Decentralized > 6/ ... > More in your replies. > > What about git under Windows ? Is it working ? well ? > > As for Bzr, I don't know anything about it. Any comments ? > > I suggest we discuss the pros an cos of all of them for a week, and then, launch a vote . > > Cheers > > Gaëtan > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel |
From: <si...@mu...> - 2013-10-29 17:32:43
|
> I suggest we discuss the pros an cos of all of them for a week, and then, > launch a vote . I would vote for Git, simply because I'm already using it and have no experience with HG. I believe that there is little difference between the two. The main reason we might want to go this way is that it would enable developers to work colaboratively outside the scope of the official branch, and hopefully speed up development and patching. It would not be a requirement to move the offical branch to git, we could just put a clone of SVN on GitHub (or somewhere) and use that for a playground. Here's some suggestions on how to get SF running a git repo: http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git What's probably more important is getting devs used to the idea of pushing out unfinished code.... ;-) Simon |
From: Xavier B. <ber...@ya...> - 2013-10-29 21:25:05
|
Hi Simon, my question was on migrate SF SVN on SF GIT, opening a git depot will not help to make updates to branch outside a git repository to trunk / svn if there is too much difference. have an external git will not help you for testing patches, as this would require the devs to have two local deposits, SVN and GIT. For me, or we keep SVN or we migrate on GIT or other. I don't think disperse the project, deposit, wiki, tickets, mailing was a good idea. Cheers Xavier Le 29/10/2013 18:32, si...@mu... a écrit : >> > I suggest we discuss the pros an cos of all of them for a week, and then, >> > launch a vote . > I would vote for Git, simply because I'm already using it and have no > experience with HG. I believe that there is little difference between the > two. > > The main reason we might want to go this way is that it would enable > developers to work colaboratively outside the scope of the official > branch, and hopefully speed up development and patching. > > It would not be a requirement to move the offical branch to git, we could > just put a clone of SVN on GitHub (or somewhere) and use that for a > playground. > > Here's some suggestions on how to get SF running a git repo: > http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git > > What's probably more important is getting devs used to the idea of pushing > out unfinished code.... ;-) |
From: Gaëtan A. <gae...@gm...> - 2013-11-12 16:44:42
|
Hi Joe, You do not care for any solutions ? Cheers, Gaëtan 2013/11/12 Joe <min...@ea...> > Hi Gaëtan, all, > I will change my vote to 'do not care' > If we do switch, let's try to preserve history. > > Cheers, > Joe > > > On 11/12/2013 7:34 AM, Gaëtan André wrote: > > After verification, History can be preserved if a bit more work.http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git#Subversion > > This page is available in a lot of languages. > > Gaëtan > > > 2013/11/12 Gaëtan André <gae...@gm...> <gae...@gm...> > > Hi Wolf-Dieter, Joe, all, > > I am sending this mail to convince you that moving to Git would be a > improvement for the project. I will also try to answer Joe's questions > (which should have been done before, sorry ...). > > Wolf-Dieter since you often report being annoyed by big updates. If Git is > adopted, this will no longer be the case : it is faster. > > We all are aware that what slows the updates are due too the versionning > of graphical data. An alternative could be to split the repo in two : > 1/ we could put the source code in a git repo > 2/ we could let graphical/sound data in svn. > > In that way, the first checkout would be quite fast, and source updates > super-fast (because git operations are a lot faster than the SVN equivalent > operations). We wouldn't have to checkout the graphical data again, which > indeed would be time consuming. Staying in svn for graphical data would not > be a big problem (apart from having to maintain 2 repos instead of one), > since for them branching does not really make sense (But if we need > branching on graphical data we need to use Git as well for them, it will > save more space : Git does not copy files when branching). > > Simon pointed out that branching and local branching would be easier to > contribute to the source code of SD, I do share is opinion. It would be > easier and faster for all of us to test each others work. Plus, we could > have on the repo several branch corresponding to different stability states > of our code. Note that in git branching is free : it does not cost time nor > space. > > Here are Joe's questions and the answers : > > 1/What are we trying to gain by switching? > I hope I have answered this question. > > 2/Anyone have any idea how disruptive changing might be? > The two main annoyances would be the loss of history and the fact that git > is not integrated with Trac. > > 3/How long will the repo be unavailable? > A few hours. > > 3/ How big of an effort and who will do it? > If we decide to move all the repo to git, it might be less an effort than > separating data from source code, but it might worth it. > > I presented a intermediate solution that could be a good compromise for > everyone (although I personally think everything should be on Git). What do > you think of this solution ? > > If you want to know more on Git, I advise you to read the very well > explain free book : http://git-scm.com/book . It is available in various > languages. It will give you hints on how using Git appropriately (it is not > the same philosophy as svn). It also presents various work flows that we > could try to use with SD. Lastly, it explains why it is super efficient at > branching. It can be read in details in 4 hours (I am a slow reader). > > Cheers, > > Gaëtan > > > > > 2013/10/31 Gaëtan André <gae...@gm...> <gae...@gm...> > > Vote has not been launched yet ^^. We are in discussion phase. > > > 2013/10/31 Wolf-Dieter Beelitz <wd...@wd...> <wd...@wd...> > > Hi all, > > > I am also a long time SVN user and have no problem staying with it. > I haven't used Bazaar at all. > I have used a couple of other proprietary systems. > > So do I and I used Mercurial but did not like it. > > > IMO there is always an amount of work to merge a branch back into the > > trunk. > > The effort is proportional to how long the branch lives as a separate > > entity. > That is what I see with other projects as well. > > I'm very restricted in time (Job and family), so I do not like to spend > time to change the repo software. > SVN is installed at all PCs and laptops I can use for SD, because we use > it for other projects as well. > > Therefore I vote to keep SVN. > > Cheers > > Wolf-Dieter > > > -----Ursprüngliche Nachricht----- > Von: Joe [mailto:min...@ea... <min...@ea...>] > Gesendet: Mittwoch, 30. Oktober 2013 18:09 > An: spe...@li... > Betreff: Re: [Speed-dreams-devel] Choosing a new versionning software. > > Hi all, > > On 10/29/2013 4:24 PM, Xavier Bertaux wrote: > > Hi Simon, > > my question was on migrate SF SVN on SF GIT, opening a git depot will > not help to make updates to branch outside a git repository to trunk / > svn if there is too much difference. > have an external git will not help you for testing patches, as this > would require the devs to have two local deposits, SVN and GIT. > > For me, or we keep SVN or we migrate on GIT or other. I don't think > disperse the project, deposit, wiki, tickets, mailing was a good idea. > > +1 > What are we trying to gain by switching? > Anyone have any idea how disruptive changing might be? > How long will the repo be unavailable? > How big of an effort and who will do it? > > I am learning git and I like the local branching. I think that it makes > managing and testing patches easier. > I am also a long time SVN user and have no problem staying with it. > (since it requires no effort or down time). > I haven't used Bazaar of Mercurial at all. I have used a couple of other > proprietary systems. IMO there is always an amount of work to merge a > branch back into the trunk. The effort is proportional to how long the > branch lives as a separate entity. > > > Cheers > Xavier > > Le 29/10/2013 18:32, si...@mu... a écrit : > > I suggest we discuss the pros an cos of all of them for a week, and > then, launch a vote . > > I would vote for Git, simply because I'm already using it and have no > experience with HG. I believe that there is little difference between > the two. > > The main reason we might want to go this way is that it would enable > developers to work colaboratively outside the scope of the official > branch, and hopefully speed up development and patching. > > It would not be a requirement to move the offical branch to git, we > could just put a clone of SVN on GitHub (or somewhere) and use that > for a playground. > > Here's some suggestions on how to get SF running a git repo:http://danielpocock.com/migrating-a-sourceforge-project-from-subversi > on-to-git > > What's probably more important is getting devs used to the idea of > pushing out unfinished code.... ;-) > > Cheers, > > Joe > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform > that developers love is also attractive to malware creators. Download this > white paper to learn more about secure code signing practices that can help > keep Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform > that > developers love is also attractive to malware creators. Download this > white > paper to learn more about secure code signing practices that can help > keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and registerhttp://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Speed-dreams-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > > |
From: Joe <min...@ea...> - 2013-11-12 18:11:27
|
Hi, I will be content with whatever everyone decides. Cheers, Joe On 11/12/2013 10:44 AM, Gaëtan André wrote: > Hi Joe, > > You do not care for any solutions ? > > Cheers, > Gaëtan > > > 2013/11/12 Joe <min...@ea...> > >> Hi Gaëtan, all, >> I will change my vote to 'do not care' >> If we do switch, let's try to preserve history. >> >> Cheers, >> Joe >> >> >> On 11/12/2013 7:34 AM, Gaëtan André wrote: >> >> After verification, History can be preserved if a bit more work.http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git#Subversion >> >> This page is available in a lot of languages. >> >> Gaëtan >> >> >> 2013/11/12 Gaëtan André <gae...@gm...> <gae...@gm...> >> >> Hi Wolf-Dieter, Joe, all, >> >> I am sending this mail to convince you that moving to Git would be a >> improvement for the project. I will also try to answer Joe's questions >> (which should have been done before, sorry ...). >> >> Wolf-Dieter since you often report being annoyed by big updates. If Git is >> adopted, this will no longer be the case : it is faster. >> >> We all are aware that what slows the updates are due too the versionning >> of graphical data. An alternative could be to split the repo in two : >> 1/ we could put the source code in a git repo >> 2/ we could let graphical/sound data in svn. >> >> In that way, the first checkout would be quite fast, and source updates >> super-fast (because git operations are a lot faster than the SVN equivalent >> operations). We wouldn't have to checkout the graphical data again, which >> indeed would be time consuming. Staying in svn for graphical data would not >> be a big problem (apart from having to maintain 2 repos instead of one), >> since for them branching does not really make sense (But if we need >> branching on graphical data we need to use Git as well for them, it will >> save more space : Git does not copy files when branching). >> >> Simon pointed out that branching and local branching would be easier to >> contribute to the source code of SD, I do share is opinion. It would be >> easier and faster for all of us to test each others work. Plus, we could >> have on the repo several branch corresponding to different stability states >> of our code. Note that in git branching is free : it does not cost time nor >> space. >> >> Here are Joe's questions and the answers : >> >> 1/What are we trying to gain by switching? >> I hope I have answered this question. >> >> 2/Anyone have any idea how disruptive changing might be? >> The two main annoyances would be the loss of history and the fact that git >> is not integrated with Trac. >> >> 3/How long will the repo be unavailable? >> A few hours. >> >> 3/ How big of an effort and who will do it? >> If we decide to move all the repo to git, it might be less an effort than >> separating data from source code, but it might worth it. >> >> I presented a intermediate solution that could be a good compromise for >> everyone (although I personally think everything should be on Git). What do >> you think of this solution ? >> >> If you want to know more on Git, I advise you to read the very well >> explain free book : http://git-scm.com/book . It is available in various >> languages. It will give you hints on how using Git appropriately (it is not >> the same philosophy as svn). It also presents various work flows that we >> could try to use with SD. Lastly, it explains why it is super efficient at >> branching. It can be read in details in 4 hours (I am a slow reader). >> >> Cheers, >> >> Gaëtan >> >> >> >> >> 2013/10/31 Gaëtan André <gae...@gm...> <gae...@gm...> >> >> Vote has not been launched yet ^^. We are in discussion phase. >> >> >> 2013/10/31 Wolf-Dieter Beelitz <wd...@wd...> <wd...@wd...> >> >> Hi all, >> >> >> I am also a long time SVN user and have no problem staying with it. >> I haven't used Bazaar at all. >> I have used a couple of other proprietary systems. >> >> So do I and I used Mercurial but did not like it. >> >> >> IMO there is always an amount of work to merge a branch back into the >> >> trunk. >> >> The effort is proportional to how long the branch lives as a separate >> >> entity. >> That is what I see with other projects as well. >> >> I'm very restricted in time (Job and family), so I do not like to spend >> time to change the repo software. >> SVN is installed at all PCs and laptops I can use for SD, because we use >> it for other projects as well. >> >> Therefore I vote to keep SVN. >> >> Cheers >> >> Wolf-Dieter >> >> >> -----Ursprüngliche Nachricht----- >> Von: Joe [mailto:min...@ea... <min...@ea...>] >> Gesendet: Mittwoch, 30. Oktober 2013 18:09 >> An: spe...@li... >> Betreff: Re: [Speed-dreams-devel] Choosing a new versionning software. >> >> Hi all, >> >> On 10/29/2013 4:24 PM, Xavier Bertaux wrote: >> >> Hi Simon, >> >> my question was on migrate SF SVN on SF GIT, opening a git depot will >> not help to make updates to branch outside a git repository to trunk / >> svn if there is too much difference. >> have an external git will not help you for testing patches, as this >> would require the devs to have two local deposits, SVN and GIT. >> >> For me, or we keep SVN or we migrate on GIT or other. I don't think >> disperse the project, deposit, wiki, tickets, mailing was a good idea. >> >> +1 >> What are we trying to gain by switching? >> Anyone have any idea how disruptive changing might be? >> How long will the repo be unavailable? >> How big of an effort and who will do it? >> >> I am learning git and I like the local branching. I think that it makes >> managing and testing patches easier. >> I am also a long time SVN user and have no problem staying with it. >> (since it requires no effort or down time). >> I haven't used Bazaar of Mercurial at all. I have used a couple of other >> proprietary systems. IMO there is always an amount of work to merge a >> branch back into the trunk. The effort is proportional to how long the >> branch lives as a separate entity. >> >> >> Cheers >> Xavier >> >> Le 29/10/2013 18:32, si...@mu... a écrit : >> >> I suggest we discuss the pros an cos of all of them for a week, and >> then, launch a vote . >> >> I would vote for Git, simply because I'm already using it and have no >> experience with HG. I believe that there is little difference between >> the two. >> >> The main reason we might want to go this way is that it would enable >> developers to work colaboratively outside the scope of the official >> branch, and hopefully speed up development and patching. >> >> It would not be a requirement to move the offical branch to git, we >> could just put a clone of SVN on GitHub (or somewhere) and use that >> for a playground. >> >> Here's some suggestions on how to get SF running a git repo:http://danielpocock.com/migrating-a-sourceforge-project-from-subversi >> on-to-git >> >> What's probably more important is getting devs used to the idea of >> pushing out unfinished code.... ;-) >> >> Cheers, >> >> Joe >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that developers love is also attractive to malware creators. Download this >> white paper to learn more about secure code signing practices that can help >> keep Android apps secure. >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Speed-dreams-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help >> keep >> Android apps secure. >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Speed-dreams-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >> >> >> >> ------------------------------------------------------------------------------ >> November Webinars for C, C++, Fortran Developers >> Accelerate application performance with scalable programming models. Explore >> techniques for threading, error checking, porting, and tuning. Get the most >> from the latest Intel processors and coprocessors. See abstracts and registerhttp://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >> >> >> >> _______________________________________________ >> Speed-dreams-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> November Webinars for C, C++, Fortran Developers >> Accelerate application performance with scalable programming models. >> Explore >> techniques for threading, error checking, porting, and tuning. Get the most >> from the latest Intel processors and coprocessors. See abstracts and >> register >> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Speed-dreams-devel mailing list >> Spe...@li... >> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >> >> > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel |
From: madbad <mad...@gm...> - 2013-10-29 17:35:52
|
I have no real knowledge of versionning softwares: I barely use git and svn but just for simple thing like checkout and commit on private projects. One thing that is not really good about git (I think is already been said here on the mailing list) is that it have a reputation of being "slow" with big binary files (images on our case), on the other hand it is probably the most used today by other projects. So: do whatever you consider best! Cheers, MadBad 2013/10/29 Gaëtan André <gae...@gm...> > Hi all, > > This mail follow the Xavier's mail on Release 2.1. > > We are currently using SVN which have major cons : > 1/ Operations are slow, especially checkout. > 2/ Branching is a headache > 3/ Too centralise > 4/ ... > More in your replies. > > Alternatives : Git, Hg (Mercurrial) and Bzr (Bazaar). > > AFAIK (correct me if I am wrong) Git and Hg are more or less the same from > a user point of view. I have never used Hg, but here are the pros of git : > 1/Very fast operations > 2/Easy local branching > 3/Easy remote branching > 4/Local commits > 5/Decentralized > 6/ ... > More in your replies. > > What about git under Windows ? Is it working ? well ? > > As for Bzr, I don't know anything about it. Any comments ? > > I suggest we discuss the pros an cos of all of them for a week, and then, > launch a vote . > > Cheers > > Gaëtan > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > > |
From: Gaëtan A. <gae...@gm...> - 2013-10-30 09:07:26
|
---------- Forwarded message ---------- From: Gaëtan André <gae...@gm...> Date: 2013/10/29 Subject: Re: [Speed-dreams-devel] Choosing a new versionning software. To: Xavier Bertaux <ber...@ya...> Hi all, I agree with Xavier. No need to have have repos everywhere. One repo on SF is enough (if we choose git) : but we can do a lot of branch there. Simon why would you want playground branches to be anywhere but on SF ? I guess that choosing bazaar implies moving to Launchpad ? Personally I am more accustomed to git. Do anyone know Bzr ? Cheers, Gaëtan 2013/10/29 Xavier Bertaux <ber...@ya...> > Hi Simon, > > my question was on migrate SF SVN on SF GIT, opening a git depot will > not help to make updates to branch outside a git repository to trunk / > svn if there is too much difference. > have an external git will not help you for testing patches, as this > would require the devs to have two local deposits, SVN and GIT. > > For me, or we keep SVN or we migrate on GIT or other. I don't > think disperse the project, deposit, wiki, tickets, mailing was a good > idea. > > Cheers > Xavier > > Le 29/10/2013 18:32, si...@mu... a écrit : > >> > I suggest we discuss the pros an cos of all of them for a week, and > then, > >> > launch a vote . > > I would vote for Git, simply because I'm already using it and have no > > experience with HG. I believe that there is little difference between the > > two. > > > > The main reason we might want to go this way is that it would enable > > developers to work colaboratively outside the scope of the official > > branch, and hopefully speed up development and patching. > > > > It would not be a requirement to move the offical branch to git, we could > > just put a clone of SVN on GitHub (or somewhere) and use that for a > > playground. > > > > Here's some suggestions on how to get SF running a git repo: > > > http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git > > > > What's probably more important is getting devs used to the idea of > pushing > > out unfinished code.... ;-) > > |
From: Gaëtan A. <gae...@gm...> - 2013-10-30 09:09:45
|
Some links on comparation. Warning, some may not be un biased. http://wiki.bazaar.canonical.com/BzrVsGit http://wiki.bazaar.canonical.com/BzrVsHg http://www.wikivs.com/wiki/Git_vs_Mercurial Does SF support bzr ? Gaëtan 2013/10/30 Gaëtan André <gae...@gm...> > > > ---------- Forwarded message ---------- > From: Gaëtan André <gae...@gm...> > Date: 2013/10/29 > Subject: Re: [Speed-dreams-devel] Choosing a new versionning software. > To: Xavier Bertaux <ber...@ya...> > > > Hi all, > > I agree with Xavier. No need to have have repos everywhere. One repo on SF > is enough (if we choose git) : but we can do a lot of branch there. Simon > why would you want playground branches to be anywhere but on SF ? > > I guess that choosing bazaar implies moving to Launchpad ? > > Personally I am more accustomed to git. > > Do anyone know Bzr ? > > > Cheers, > Gaëtan > > > 2013/10/29 Xavier Bertaux <ber...@ya...> > >> Hi Simon, >> >> my question was on migrate SF SVN on SF GIT, opening a git depot will >> not help to make updates to branch outside a git repository to trunk / >> svn if there is too much difference. >> have an external git will not help you for testing patches, as this >> would require the devs to have two local deposits, SVN and GIT. >> >> For me, or we keep SVN or we migrate on GIT or other. I don't >> think disperse the project, deposit, wiki, tickets, mailing was a good >> idea. >> >> Cheers >> Xavier >> >> Le 29/10/2013 18:32, si...@mu... a écrit : >> >> > I suggest we discuss the pros an cos of all of them for a week, and >> then, >> >> > launch a vote . >> > I would vote for Git, simply because I'm already using it and have no >> > experience with HG. I believe that there is little difference between >> the >> > two. >> > >> > The main reason we might want to go this way is that it would enable >> > developers to work colaboratively outside the scope of the official >> > branch, and hopefully speed up development and patching. >> > >> > It would not be a requirement to move the offical branch to git, we >> could >> > just put a clone of SVN on GitHub (or somewhere) and use that for a >> > playground. >> > >> > Here's some suggestions on how to get SF running a git repo: >> > >> http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git >> > >> > What's probably more important is getting devs used to the idea of >> pushing >> > out unfinished code.... ;-) >> >> > > |
From: Gaëtan A. <gae...@gm...> - 2013-10-30 09:12:23
|
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ 2013/10/30 Gaëtan André <gae...@gm...> > Some links on comparation. Warning, some may not be un biased. > > http://wiki.bazaar.canonical.com/BzrVsGit > http://wiki.bazaar.canonical.com/BzrVsHg > http://www.wikivs.com/wiki/Git_vs_Mercurial > > Does SF support bzr ? > > Gaëtan > > > 2013/10/30 Gaëtan André <gae...@gm...> > >> >> >> ---------- Forwarded message ---------- >> From: Gaëtan André <gae...@gm...> >> Date: 2013/10/29 >> Subject: Re: [Speed-dreams-devel] Choosing a new versionning software. >> To: Xavier Bertaux <ber...@ya...> >> >> >> Hi all, >> >> I agree with Xavier. No need to have have repos everywhere. One repo on >> SF is enough (if we choose git) : but we can do a lot of branch there. >> Simon why would you want playground branches to be anywhere but on SF ? >> >> I guess that choosing bazaar implies moving to Launchpad ? >> >> Personally I am more accustomed to git. >> >> Do anyone know Bzr ? >> >> >> Cheers, >> Gaëtan >> >> >> 2013/10/29 Xavier Bertaux <ber...@ya...> >> >>> Hi Simon, >>> >>> my question was on migrate SF SVN on SF GIT, opening a git depot will >>> not help to make updates to branch outside a git repository to trunk / >>> svn if there is too much difference. >>> have an external git will not help you for testing patches, as this >>> would require the devs to have two local deposits, SVN and GIT. >>> >>> For me, or we keep SVN or we migrate on GIT or other. I don't >>> think disperse the project, deposit, wiki, tickets, mailing was a good >>> idea. >>> >>> Cheers >>> Xavier >>> >>> Le 29/10/2013 18:32, si...@mu... a écrit : >>> >> > I suggest we discuss the pros an cos of all of them for a week, and >>> then, >>> >> > launch a vote . >>> > I would vote for Git, simply because I'm already using it and have no >>> > experience with HG. I believe that there is little difference between >>> the >>> > two. >>> > >>> > The main reason we might want to go this way is that it would enable >>> > developers to work colaboratively outside the scope of the official >>> > branch, and hopefully speed up development and patching. >>> > >>> > It would not be a requirement to move the offical branch to git, we >>> could >>> > just put a clone of SVN on GitHub (or somewhere) and use that for a >>> > playground. >>> > >>> > Here's some suggestions on how to get SF running a git repo: >>> > >>> http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git >>> > >>> > What's probably more important is getting devs used to the idea of >>> pushing >>> > out unfinished code.... ;-) >>> >>> >> >> > |
From: Xavier B. <ber...@ya...> - 2013-10-30 12:20:31
|
No SF don t support bazaars Envoyé de mon iPhone > Le 30 oct. 2013 à 10:09, Gaëtan André <gae...@gm...> a écrit : > > Some links on comparation. Warning, some may not be un biased. > > http://wiki.bazaar.canonical.com/BzrVsGit > http://wiki.bazaar.canonical.com/BzrVsHg > http://www.wikivs.com/wiki/Git_vs_Mercurial > > Does SF support bzr ? > > Gaëtan > > > 2013/10/30 Gaëtan André <gae...@gm...> >> >> >> ---------- Forwarded message ---------- >> From: Gaëtan André <gae...@gm...> >> Date: 2013/10/29 >> Subject: Re: [Speed-dreams-devel] Choosing a new versionning software. >> To: Xavier Bertaux <ber...@ya...> >> >> >> Hi all, >> >> I agree with Xavier. No need to have have repos everywhere. One repo on SF is enough (if we choose git) : but we can do a lot of branch there. Simon why would you want playground branches to be anywhere but on SF ? >> >> I guess that choosing bazaar implies moving to Launchpad ? >> >> Personally I am more accustomed to git. >> >> Do anyone know Bzr ? >> >> >> Cheers, >> Gaëtan >> >> >> 2013/10/29 Xavier Bertaux <ber...@ya...> >>> Hi Simon, >>> >>> my question was on migrate SF SVN on SF GIT, opening a git depot will >>> not help to make updates to branch outside a git repository to trunk / >>> svn if there is too much difference. >>> have an external git will not help you for testing patches, as this >>> would require the devs to have two local deposits, SVN and GIT. >>> >>> For me, or we keep SVN or we migrate on GIT or other. I don't >>> think disperse the project, deposit, wiki, tickets, mailing was a good idea. >>> >>> Cheers >>> Xavier >>> >>> Le 29/10/2013 18:32, si...@mu... a écrit : >>> >> > I suggest we discuss the pros an cos of all of them for a week, and then, >>> >> > launch a vote . >>> > I would vote for Git, simply because I'm already using it and have no >>> > experience with HG. I believe that there is little difference between the >>> > two. >>> > >>> > The main reason we might want to go this way is that it would enable >>> > developers to work colaboratively outside the scope of the official >>> > branch, and hopefully speed up development and patching. >>> > >>> > It would not be a requirement to move the offical branch to git, we could >>> > just put a clone of SVN on GitHub (or somewhere) and use that for a >>> > playground. >>> > >>> > Here's some suggestions on how to get SF running a git repo: >>> > http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git >>> > >>> > What's probably more important is getting devs used to the idea of pushing >>> > out unfinished code.... ;-) > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel |
From: Joe <min...@ea...> - 2013-10-30 17:09:00
|
Hi all, On 10/29/2013 4:24 PM, Xavier Bertaux wrote: > Hi Simon, > > my question was on migrate SF SVN on SF GIT, opening a git depot will > not help to make updates to branch outside a git repository to trunk / > svn if there is too much difference. > have an external git will not help you for testing patches, as this > would require the devs to have two local deposits, SVN and GIT. > > For me, or we keep SVN or we migrate on GIT or other. I don't > think disperse the project, deposit, wiki, tickets, mailing was a good idea. +1 What are we trying to gain by switching? Anyone have any idea how disruptive changing might be? How long will the repo be unavailable? How big of an effort and who will do it? I am learning git and I like the local branching. I think that it makes managing and testing patches easier. I am also a long time SVN user and have no problem staying with it. (since it requires no effort or down time). I haven't used Bazaar of Mercurial at all. I have used a couple of other proprietary systems. IMO there is always an amount of work to merge a branch back into the trunk. The effort is proportional to how long the branch lives as a separate entity. > Cheers > Xavier > > Le 29/10/2013 18:32, si...@mu... a écrit : >>>> I suggest we discuss the pros an cos of all of them for a week, and then, >>>> launch a vote . >> I would vote for Git, simply because I'm already using it and have no >> experience with HG. I believe that there is little difference between the >> two. >> >> The main reason we might want to go this way is that it would enable >> developers to work colaboratively outside the scope of the official >> branch, and hopefully speed up development and patching. >> >> It would not be a requirement to move the offical branch to git, we could >> just put a clone of SVN on GitHub (or somewhere) and use that for a >> playground. >> >> Here's some suggestions on how to get SF running a git repo: >> http://danielpocock.com/migrating-a-sourceforge-project-from-subversion-to-git >> >> What's probably more important is getting devs used to the idea of pushing >> out unfinished code.... ;-) > Cheers, Joe |
From: Wolf-Dieter B. <wd...@wd...> - 2013-10-31 07:06:06
|
Hi all, > I am also a long time SVN user and have no problem staying with it. > I haven't used Bazaar at all. > I have used a couple of other proprietary systems. So do I and I used Mercurial but did not like it. > IMO there is always an amount of work to merge a branch back into the trunk. > The effort is proportional to how long the branch lives as a separate entity. That is what I see with other projects as well. I'm very restricted in time (Job and family), so I do not like to spend time to change the repo software. SVN is installed at all PCs and laptops I can use for SD, because we use it for other projects as well. Therefore I vote to keep SVN. Cheers Wolf-Dieter -----Ursprüngliche Nachricht----- Von: Joe [mailto:min...@ea...] Gesendet: Mittwoch, 30. Oktober 2013 18:09 An: spe...@li... Betreff: Re: [Speed-dreams-devel] Choosing a new versionning software. Hi all, On 10/29/2013 4:24 PM, Xavier Bertaux wrote: > Hi Simon, > > my question was on migrate SF SVN on SF GIT, opening a git depot will > not help to make updates to branch outside a git repository to trunk / > svn if there is too much difference. > have an external git will not help you for testing patches, as this > would require the devs to have two local deposits, SVN and GIT. > > For me, or we keep SVN or we migrate on GIT or other. I don't think > disperse the project, deposit, wiki, tickets, mailing was a good idea. +1 What are we trying to gain by switching? Anyone have any idea how disruptive changing might be? How long will the repo be unavailable? How big of an effort and who will do it? I am learning git and I like the local branching. I think that it makes managing and testing patches easier. I am also a long time SVN user and have no problem staying with it. (since it requires no effort or down time). I haven't used Bazaar of Mercurial at all. I have used a couple of other proprietary systems. IMO there is always an amount of work to merge a branch back into the trunk. The effort is proportional to how long the branch lives as a separate entity. > Cheers > Xavier > > Le 29/10/2013 18:32, si...@mu... a écrit : >>>> I suggest we discuss the pros an cos of all of them for a week, and >>>> then, launch a vote . >> I would vote for Git, simply because I'm already using it and have no >> experience with HG. I believe that there is little difference between >> the two. >> >> The main reason we might want to go this way is that it would enable >> developers to work colaboratively outside the scope of the official >> branch, and hopefully speed up development and patching. >> >> It would not be a requirement to move the offical branch to git, we >> could just put a clone of SVN on GitHub (or somewhere) and use that >> for a playground. >> >> Here's some suggestions on how to get SF running a git repo: >> http://danielpocock.com/migrating-a-sourceforge-project-from-subversi >> on-to-git >> >> What's probably more important is getting devs used to the idea of >> pushing out unfinished code.... ;-) > Cheers, Joe ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Speed-dreams-devel mailing list Spe...@li... https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel |
From: Gaëtan A. <gae...@gm...> - 2013-10-31 08:42:33
|
Vote has not been launched yet ^^. We are in discussion phase. 2013/10/31 Wolf-Dieter Beelitz <wd...@wd...> > Hi all, > > > I am also a long time SVN user and have no problem staying with it. > > I haven't used Bazaar at all. > > I have used a couple of other proprietary systems. > So do I and I used Mercurial but did not like it. > > > IMO there is always an amount of work to merge a branch back into the > trunk. > > The effort is proportional to how long the branch lives as a separate > entity. > That is what I see with other projects as well. > > I'm very restricted in time (Job and family), so I do not like to spend > time to change the repo software. > SVN is installed at all PCs and laptops I can use for SD, because we use > it for other projects as well. > > Therefore I vote to keep SVN. > > Cheers > > Wolf-Dieter > > > -----Ursprüngliche Nachricht----- > Von: Joe [mailto:min...@ea...] > Gesendet: Mittwoch, 30. Oktober 2013 18:09 > An: spe...@li... > Betreff: Re: [Speed-dreams-devel] Choosing a new versionning software. > > Hi all, > > On 10/29/2013 4:24 PM, Xavier Bertaux wrote: > > Hi Simon, > > > > my question was on migrate SF SVN on SF GIT, opening a git depot will > > not help to make updates to branch outside a git repository to trunk / > > svn if there is too much difference. > > have an external git will not help you for testing patches, as this > > would require the devs to have two local deposits, SVN and GIT. > > > > For me, or we keep SVN or we migrate on GIT or other. I don't think > > disperse the project, deposit, wiki, tickets, mailing was a good idea. > +1 > What are we trying to gain by switching? > Anyone have any idea how disruptive changing might be? > How long will the repo be unavailable? > How big of an effort and who will do it? > > I am learning git and I like the local branching. I think that it makes > managing and testing patches easier. > I am also a long time SVN user and have no problem staying with it. > (since it requires no effort or down time). > I haven't used Bazaar of Mercurial at all. I have used a couple of other > proprietary systems. IMO there is always an amount of work to merge a > branch back into the trunk. The effort is proportional to how long the > branch lives as a separate entity. > > > Cheers > > Xavier > > > > Le 29/10/2013 18:32, si...@mu... a écrit : > >>>> I suggest we discuss the pros an cos of all of them for a week, and > >>>> then, launch a vote . > >> I would vote for Git, simply because I'm already using it and have no > >> experience with HG. I believe that there is little difference between > >> the two. > >> > >> The main reason we might want to go this way is that it would enable > >> developers to work colaboratively outside the scope of the official > >> branch, and hopefully speed up development and patching. > >> > >> It would not be a requirement to move the offical branch to git, we > >> could just put a clone of SVN on GitHub (or somewhere) and use that > >> for a playground. > >> > >> Here's some suggestions on how to get SF running a git repo: > >> http://danielpocock.com/migrating-a-sourceforge-project-from-subversi > >> on-to-git > >> > >> What's probably more important is getting devs used to the idea of > >> pushing out unfinished code.... ;-) > > Cheers, > Joe > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform > that developers love is also attractive to malware creators. Download this > white paper to learn more about secure code signing practices that can help > keep Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > |
From: Gaëtan A. <gae...@gm...> - 2013-11-12 09:29:58
|
Hi Wolf-Dieter, Joe, all, I am sending this mail to convince you that moving to Git would be a improvement for the project. I will also try to answer Joe's questions (which should have been done before, sorry ...). Wolf-Dieter since you often report being annoyed by big updates. If Git is adopted, this will no longer be the case : it is faster. We all are aware that what slows the updates are due too the versionning of graphical data. An alternative could be to split the repo in two : 1/ we could put the source code in a git repo 2/ we could let graphical/sound data in svn. In that way, the first checkout would be quite fast, and source updates super-fast (because git operations are a lot faster than the SVN equivalent operations). We wouldn't have to checkout the graphical data again, which indeed would be time consuming. Staying in svn for graphical data would not be a big problem (apart from having to maintain 2 repos instead of one), since for them branching does not really make sense (But if we need branching on graphical data we need to use Git as well for them, it will save more space : Git does not copy files when branching). Simon pointed out that branching and local branching would be easier to contribute to the source code of SD, I do share is opinion. It would be easier and faster for all of us to test each others work. Plus, we could have on the repo several branch corresponding to different stability states of our code. Note that in git branching is free : it does not cost time nor space. Here are Joe's questions and the answers : 1/What are we trying to gain by switching? I hope I have answered this question. 2/Anyone have any idea how disruptive changing might be? The two main annoyances would be the loss of history and the fact that git is not integrated with Trac. 3/How long will the repo be unavailable? A few hours. 3/ How big of an effort and who will do it? If we decide to move all the repo to git, it might be less an effort than separating data from source code, but it might worth it. I presented a intermediate solution that could be a good compromise for everyone (although I personally think everything should be on Git). What do you think of this solution ? If you want to know more on Git, I advise you to read the very well explain free book : http://git-scm.com/book . It is available in various languages. It will give you hints on how using Git appropriately (it is not the same philosophy as svn). It also presents various work flows that we could try to use with SD. Lastly, it explains why it is super efficient at branching. It can be read in details in 4 hours (I am a slow reader). Cheers, Gaëtan 2013/10/31 Gaëtan André <gae...@gm...> > Vote has not been launched yet ^^. We are in discussion phase. > > > 2013/10/31 Wolf-Dieter Beelitz <wd...@wd...> > >> Hi all, >> >> > I am also a long time SVN user and have no problem staying with it. >> > I haven't used Bazaar at all. >> > I have used a couple of other proprietary systems. >> So do I and I used Mercurial but did not like it. >> >> > IMO there is always an amount of work to merge a branch back into the >> trunk. >> > The effort is proportional to how long the branch lives as a separate >> entity. >> That is what I see with other projects as well. >> >> I'm very restricted in time (Job and family), so I do not like to spend >> time to change the repo software. >> SVN is installed at all PCs and laptops I can use for SD, because we use >> it for other projects as well. >> >> Therefore I vote to keep SVN. >> >> Cheers >> >> Wolf-Dieter >> >> >> -----Ursprüngliche Nachricht----- >> Von: Joe [mailto:min...@ea...] >> Gesendet: Mittwoch, 30. Oktober 2013 18:09 >> An: spe...@li... >> Betreff: Re: [Speed-dreams-devel] Choosing a new versionning software. >> >> Hi all, >> >> On 10/29/2013 4:24 PM, Xavier Bertaux wrote: >> > Hi Simon, >> > >> > my question was on migrate SF SVN on SF GIT, opening a git depot will >> > not help to make updates to branch outside a git repository to trunk / >> > svn if there is too much difference. >> > have an external git will not help you for testing patches, as this >> > would require the devs to have two local deposits, SVN and GIT. >> > >> > For me, or we keep SVN or we migrate on GIT or other. I don't think >> > disperse the project, deposit, wiki, tickets, mailing was a good idea. >> +1 >> What are we trying to gain by switching? >> Anyone have any idea how disruptive changing might be? >> How long will the repo be unavailable? >> How big of an effort and who will do it? >> >> I am learning git and I like the local branching. I think that it makes >> managing and testing patches easier. >> I am also a long time SVN user and have no problem staying with it. >> (since it requires no effort or down time). >> I haven't used Bazaar of Mercurial at all. I have used a couple of other >> proprietary systems. IMO there is always an amount of work to merge a >> branch back into the trunk. The effort is proportional to how long the >> branch lives as a separate entity. >> >> > Cheers >> > Xavier >> > >> > Le 29/10/2013 18:32, si...@mu... a écrit : >> >>>> I suggest we discuss the pros an cos of all of them for a week, and >> >>>> then, launch a vote . >> >> I would vote for Git, simply because I'm already using it and have no >> >> experience with HG. I believe that there is little difference between >> >> the two. >> >> >> >> The main reason we might want to go this way is that it would enable >> >> developers to work colaboratively outside the scope of the official >> >> branch, and hopefully speed up development and patching. >> >> >> >> It would not be a requirement to move the offical branch to git, we >> >> could just put a clone of SVN on GitHub (or somewhere) and use that >> >> for a playground. >> >> >> >> Here's some suggestions on how to get SF running a git repo: >> >> http://danielpocock.com/migrating-a-sourceforge-project-from-subversi >> >> on-to-git >> >> >> >> What's probably more important is getting devs used to the idea of >> >> pushing out unfinished code.... ;-) >> > Cheers, >> Joe >> >> >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that developers love is also attractive to malware creators. Download this >> white paper to learn more about secure code signing practices that can help >> keep Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Speed-dreams-devel mailing list >> Spe...@li... >> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >> >> ------------------------------------------------------------------------------ >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> _______________________________________________ >> Speed-dreams-devel mailing list >> Spe...@li... >> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >> > > |
From: Gaëtan A. <gae...@gm...> - 2013-11-12 13:35:02
|
After verification, History can be preserved if a bit more work. http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git#Subversion This page is available in a lot of languages. Gaëtan 2013/11/12 Gaëtan André <gae...@gm...> > Hi Wolf-Dieter, Joe, all, > > I am sending this mail to convince you that moving to Git would be a > improvement for the project. I will also try to answer Joe's questions > (which should have been done before, sorry ...). > > Wolf-Dieter since you often report being annoyed by big updates. If Git is > adopted, this will no longer be the case : it is faster. > > We all are aware that what slows the updates are due too the versionning > of graphical data. An alternative could be to split the repo in two : > 1/ we could put the source code in a git repo > 2/ we could let graphical/sound data in svn. > > In that way, the first checkout would be quite fast, and source updates > super-fast (because git operations are a lot faster than the SVN equivalent > operations). We wouldn't have to checkout the graphical data again, which > indeed would be time consuming. Staying in svn for graphical data would not > be a big problem (apart from having to maintain 2 repos instead of one), > since for them branching does not really make sense (But if we need > branching on graphical data we need to use Git as well for them, it will > save more space : Git does not copy files when branching). > > Simon pointed out that branching and local branching would be easier to > contribute to the source code of SD, I do share is opinion. It would be > easier and faster for all of us to test each others work. Plus, we could > have on the repo several branch corresponding to different stability states > of our code. Note that in git branching is free : it does not cost time nor > space. > > Here are Joe's questions and the answers : > > 1/What are we trying to gain by switching? > I hope I have answered this question. > > 2/Anyone have any idea how disruptive changing might be? > The two main annoyances would be the loss of history and the fact that git > is not integrated with Trac. > > 3/How long will the repo be unavailable? > A few hours. > > 3/ How big of an effort and who will do it? > If we decide to move all the repo to git, it might be less an effort than > separating data from source code, but it might worth it. > > I presented a intermediate solution that could be a good compromise for > everyone (although I personally think everything should be on Git). What do > you think of this solution ? > > If you want to know more on Git, I advise you to read the very well > explain free book : http://git-scm.com/book . It is available in various > languages. It will give you hints on how using Git appropriately (it is not > the same philosophy as svn). It also presents various work flows that we > could try to use with SD. Lastly, it explains why it is super efficient at > branching. It can be read in details in 4 hours (I am a slow reader). > > Cheers, > > Gaëtan > > > > > 2013/10/31 Gaëtan André <gae...@gm...> > >> Vote has not been launched yet ^^. We are in discussion phase. >> >> >> 2013/10/31 Wolf-Dieter Beelitz <wd...@wd...> >> >>> Hi all, >>> >>> > I am also a long time SVN user and have no problem staying with it. >>> > I haven't used Bazaar at all. >>> > I have used a couple of other proprietary systems. >>> So do I and I used Mercurial but did not like it. >>> >>> > IMO there is always an amount of work to merge a branch back into the >>> trunk. >>> > The effort is proportional to how long the branch lives as a separate >>> entity. >>> That is what I see with other projects as well. >>> >>> I'm very restricted in time (Job and family), so I do not like to spend >>> time to change the repo software. >>> SVN is installed at all PCs and laptops I can use for SD, because we use >>> it for other projects as well. >>> >>> Therefore I vote to keep SVN. >>> >>> Cheers >>> >>> Wolf-Dieter >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Joe [mailto:min...@ea...] >>> Gesendet: Mittwoch, 30. Oktober 2013 18:09 >>> An: spe...@li... >>> Betreff: Re: [Speed-dreams-devel] Choosing a new versionning software. >>> >>> Hi all, >>> >>> On 10/29/2013 4:24 PM, Xavier Bertaux wrote: >>> > Hi Simon, >>> > >>> > my question was on migrate SF SVN on SF GIT, opening a git depot will >>> > not help to make updates to branch outside a git repository to trunk / >>> > svn if there is too much difference. >>> > have an external git will not help you for testing patches, as this >>> > would require the devs to have two local deposits, SVN and GIT. >>> > >>> > For me, or we keep SVN or we migrate on GIT or other. I don't think >>> > disperse the project, deposit, wiki, tickets, mailing was a good idea. >>> +1 >>> What are we trying to gain by switching? >>> Anyone have any idea how disruptive changing might be? >>> How long will the repo be unavailable? >>> How big of an effort and who will do it? >>> >>> I am learning git and I like the local branching. I think that it makes >>> managing and testing patches easier. >>> I am also a long time SVN user and have no problem staying with it. >>> (since it requires no effort or down time). >>> I haven't used Bazaar of Mercurial at all. I have used a couple of other >>> proprietary systems. IMO there is always an amount of work to merge a >>> branch back into the trunk. The effort is proportional to how long the >>> branch lives as a separate entity. >>> >>> > Cheers >>> > Xavier >>> > >>> > Le 29/10/2013 18:32, si...@mu... a écrit : >>> >>>> I suggest we discuss the pros an cos of all of them for a week, and >>> >>>> then, launch a vote . >>> >> I would vote for Git, simply because I'm already using it and have no >>> >> experience with HG. I believe that there is little difference between >>> >> the two. >>> >> >>> >> The main reason we might want to go this way is that it would enable >>> >> developers to work colaboratively outside the scope of the official >>> >> branch, and hopefully speed up development and patching. >>> >> >>> >> It would not be a requirement to move the offical branch to git, we >>> >> could just put a clone of SVN on GitHub (or somewhere) and use that >>> >> for a playground. >>> >> >>> >> Here's some suggestions on how to get SF running a git repo: >>> >> http://danielpocock.com/migrating-a-sourceforge-project-from-subversi >>> >> on-to-git >>> >> >>> >> What's probably more important is getting devs used to the idea of >>> >> pushing out unfinished code.... ;-) >>> > Cheers, >>> Joe >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Android is increasing in popularity, but the open development platform >>> that developers love is also attractive to malware creators. Download this >>> white paper to learn more about secure code signing practices that can help >>> keep Android apps secure. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Speed-dreams-devel mailing list >>> Spe...@li... >>> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >>> >>> ------------------------------------------------------------------------------ >>> Android is increasing in popularity, but the open development platform >>> that >>> developers love is also attractive to malware creators. Download this >>> white >>> paper to learn more about secure code signing practices that can help >>> keep >>> Android apps secure. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Speed-dreams-devel mailing list >>> Spe...@li... >>> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >>> >> >> > |
From: xavier b. <ber...@ya...> - 2013-11-12 17:58:26
|
Hi All, after a few days of thinking about this problem I decided to vote to keep SVN. I will explain tonight why in a separate email. Cheers Xavier |
From: Joe <min...@ea...> - 2013-11-12 16:40:06
|
Hi Gaëtan, all, I will change my vote to 'do not care' If we do switch, let's try to preserve history. Cheers, Joe On 11/12/2013 7:34 AM, Gaëtan André wrote: > After verification, History can be preserved if a bit more work. > http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git#Subversion > > This page is available in a lot of languages. > > Gaëtan > > > 2013/11/12 Gaëtan André <gae...@gm...> > >> Hi Wolf-Dieter, Joe, all, >> >> I am sending this mail to convince you that moving to Git would be a >> improvement for the project. I will also try to answer Joe's questions >> (which should have been done before, sorry ...). >> >> Wolf-Dieter since you often report being annoyed by big updates. If Git is >> adopted, this will no longer be the case : it is faster. >> >> We all are aware that what slows the updates are due too the versionning >> of graphical data. An alternative could be to split the repo in two : >> 1/ we could put the source code in a git repo >> 2/ we could let graphical/sound data in svn. >> >> In that way, the first checkout would be quite fast, and source updates >> super-fast (because git operations are a lot faster than the SVN equivalent >> operations). We wouldn't have to checkout the graphical data again, which >> indeed would be time consuming. Staying in svn for graphical data would not >> be a big problem (apart from having to maintain 2 repos instead of one), >> since for them branching does not really make sense (But if we need >> branching on graphical data we need to use Git as well for them, it will >> save more space : Git does not copy files when branching). >> >> Simon pointed out that branching and local branching would be easier to >> contribute to the source code of SD, I do share is opinion. It would be >> easier and faster for all of us to test each others work. Plus, we could >> have on the repo several branch corresponding to different stability states >> of our code. Note that in git branching is free : it does not cost time nor >> space. >> >> Here are Joe's questions and the answers : >> >> 1/What are we trying to gain by switching? >> I hope I have answered this question. >> >> 2/Anyone have any idea how disruptive changing might be? >> The two main annoyances would be the loss of history and the fact that git >> is not integrated with Trac. >> >> 3/How long will the repo be unavailable? >> A few hours. >> >> 3/ How big of an effort and who will do it? >> If we decide to move all the repo to git, it might be less an effort than >> separating data from source code, but it might worth it. >> >> I presented a intermediate solution that could be a good compromise for >> everyone (although I personally think everything should be on Git). What do >> you think of this solution ? >> >> If you want to know more on Git, I advise you to read the very well >> explain free book : http://git-scm.com/book . It is available in various >> languages. It will give you hints on how using Git appropriately (it is not >> the same philosophy as svn). It also presents various work flows that we >> could try to use with SD. Lastly, it explains why it is super efficient at >> branching. It can be read in details in 4 hours (I am a slow reader). >> >> Cheers, >> >> Gaëtan >> >> >> >> >> 2013/10/31 Gaëtan André <gae...@gm...> >> >>> Vote has not been launched yet ^^. We are in discussion phase. >>> >>> >>> 2013/10/31 Wolf-Dieter Beelitz <wd...@wd...> >>> >>>> Hi all, >>>> >>>>> I am also a long time SVN user and have no problem staying with it. >>>>> I haven't used Bazaar at all. >>>>> I have used a couple of other proprietary systems. >>>> So do I and I used Mercurial but did not like it. >>>> >>>>> IMO there is always an amount of work to merge a branch back into the >>>> trunk. >>>>> The effort is proportional to how long the branch lives as a separate >>>> entity. >>>> That is what I see with other projects as well. >>>> >>>> I'm very restricted in time (Job and family), so I do not like to spend >>>> time to change the repo software. >>>> SVN is installed at all PCs and laptops I can use for SD, because we use >>>> it for other projects as well. >>>> >>>> Therefore I vote to keep SVN. >>>> >>>> Cheers >>>> >>>> Wolf-Dieter >>>> >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Joe [mailto:min...@ea...] >>>> Gesendet: Mittwoch, 30. Oktober 2013 18:09 >>>> An: spe...@li... >>>> Betreff: Re: [Speed-dreams-devel] Choosing a new versionning software. >>>> >>>> Hi all, >>>> >>>> On 10/29/2013 4:24 PM, Xavier Bertaux wrote: >>>>> Hi Simon, >>>>> >>>>> my question was on migrate SF SVN on SF GIT, opening a git depot will >>>>> not help to make updates to branch outside a git repository to trunk / >>>>> svn if there is too much difference. >>>>> have an external git will not help you for testing patches, as this >>>>> would require the devs to have two local deposits, SVN and GIT. >>>>> >>>>> For me, or we keep SVN or we migrate on GIT or other. I don't think >>>>> disperse the project, deposit, wiki, tickets, mailing was a good idea. >>>> +1 >>>> What are we trying to gain by switching? >>>> Anyone have any idea how disruptive changing might be? >>>> How long will the repo be unavailable? >>>> How big of an effort and who will do it? >>>> >>>> I am learning git and I like the local branching. I think that it makes >>>> managing and testing patches easier. >>>> I am also a long time SVN user and have no problem staying with it. >>>> (since it requires no effort or down time). >>>> I haven't used Bazaar of Mercurial at all. I have used a couple of other >>>> proprietary systems. IMO there is always an amount of work to merge a >>>> branch back into the trunk. The effort is proportional to how long the >>>> branch lives as a separate entity. >>>> >>>>> Cheers >>>>> Xavier >>>>> >>>>> Le 29/10/2013 18:32, si...@mu... a écrit : >>>>>>>> I suggest we discuss the pros an cos of all of them for a week, and >>>>>>>> then, launch a vote . >>>>>> I would vote for Git, simply because I'm already using it and have no >>>>>> experience with HG. I believe that there is little difference between >>>>>> the two. >>>>>> >>>>>> The main reason we might want to go this way is that it would enable >>>>>> developers to work colaboratively outside the scope of the official >>>>>> branch, and hopefully speed up development and patching. >>>>>> >>>>>> It would not be a requirement to move the offical branch to git, we >>>>>> could just put a clone of SVN on GitHub (or somewhere) and use that >>>>>> for a playground. >>>>>> >>>>>> Here's some suggestions on how to get SF running a git repo: >>>>>> http://danielpocock.com/migrating-a-sourceforge-project-from-subversi >>>>>> on-to-git >>>>>> >>>>>> What's probably more important is getting devs used to the idea of >>>>>> pushing out unfinished code.... ;-) >>>>> Cheers, >>>> Joe >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Android is increasing in popularity, but the open development platform >>>> that developers love is also attractive to malware creators. Download this >>>> white paper to learn more about secure code signing practices that can help >>>> keep Android apps secure. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Speed-dreams-devel mailing list >>>> Spe...@li... >>>> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >>>> >>>> ------------------------------------------------------------------------------ >>>> Android is increasing in popularity, but the open development platform >>>> that >>>> developers love is also attractive to malware creators. Download this >>>> white >>>> paper to learn more about secure code signing practices that can help >>>> keep >>>> Android apps secure. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Speed-dreams-devel mailing list >>>> Spe...@li... >>>> https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel >>>> >>> > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel |