Menu
▾
▴
Re: [Gwt-openlayers-devl] moving to Bitbucket
|
From: Edwin C. <com...@gm...> - 2011-02-14 23:45:30
|
Thanks for all the quick responses to the BitBucket idea. Andrew, thanks for correcting me on the fact that Google Code does host Mercurial (and Git). Hadn't caught up with that. That does open up Google Code as an option. However, it does appeal to me that Bitbucket is more Mercurial focused (though it also offers SVN) and is a bit like the popular Github site in it's social aspects. Google Code has a good write up why you would want to create a server-side clone: http://code.google.com/p/support/wiki/MercurialFAQ#Why_should_I_create_a_server-side_clone? At BitBucket they call a server-side clone a fork, and from your fork you can issue pull requests to the repo you forked. The term fork seems a bit heavy, but is nothing big in BitBucket. BitBucket has some support for static pages: http://hgtip.com/tips/beginner/2009-10-13-free-hosting-at-bitbucket/ With this workaround it should be possible to host the Maven generated website. I can have a go at that. Furthermore Farrukh is -1 on Google Code. So far I gauge you would be open to moving at least the code to BitBucket. Greetings, Edwin P.S. Open to any arguments why should stick at SF (can't see why actually) or why we should move to another Hg provider than Bitbucket. On 15 February 2011 00:15, Andrew Hughes <ahh...@gm...> wrote: > FYI: Google code offer both mercurial and subversion - the choice is yours. > Examples: > http://code.google.com/p/gwt-presenter/source/checkout > http://code.google.com/p/gwt-platform/source/checkout > Since I would support staying with mercurial I'll build on this. The ability > to create new "per developer" or "per issue" clones on sf is a very human > intensive exercise. The result is that we end up with a lot of people from > the general public submitting work (as patches as best) via email (because > they don't have access to a clone/sandbox). If bit bucket can overcome this > I see it as a big step forward. Likewise, google code has web interface to > create a "per developer", "per issue" or "per whatever" clones... > Example, here is a list of clones currently on the gwt-platform project: > http://code.google.com/p/gwt-platform/source/clones > Also, notice the button at the bottom "create a clone". I would like to know > if you can limit who can push to what clone (via .hg/hgrc) - I would hope > so. > The only thing I don't like about google code, is that you can't upload > (scp, ftp e.t.c.) your own static web content anywhere (that I know of). > This means all of the javadocs and documentation we currently deploy to sf > would remain there (but thats a different issue). > Anyway.. like Edwin I don't have much spare time, this would be really > helpful to keep the project moving forward. > Cheers > --AH > > On Tue, Feb 15, 2011 at 9:29 AM, Edwin Commandeur > <com...@gm...> wrote: >> >> That's a fast response :) >> >> Google Code would be a no-go, because it is Subversion based and the >> GWT-OpenLayers code is now in a Mercurial repository. Since Bitbucket >> focuses on services around Mercurial, it seems like a natural choice. >> Also, Mercurial is far easier to use than SF for developers, and it is >> more social and easier for people to get involved. >> >> Greetings, >> Edwin Commandeur >> >> On 14 February 2011 23:50, Dave Koberstein <da...@da...> wrote: >> > Sounds like a good plan. I've been developing a lot of TODOs that I >> > need to >> > implement one of these days. So I can stay with std gwt-openlayers I've >> > taken to poking JSObject from my code with //TODO markers to clean up >> > later. These are almost all just pulling up existing openlayers >> > parameters >> > to gwt-openlayers. So shouldn't be any surprises or controversy. :) >> > >> > We might consider google code since there are many gwt projects there >> > already. But if you prefer bitbucket, it will be nice to try out >> > something >> > new. >> > >> > Dave >> > >> > On 2/14/2011 2:45 PM, Edwin Commandeur wrote: >> > >> > Dear GWT OpenLayers developers, >> > >> > In order to make better use of the distributed version control system >> > we are using I would like to propose to move the code over to >> > Bitbucket. I would see the following advantages: >> > >> > - Easy workflow for code contributions: Any Bitbucket user can fork, >> > submit code to their fork, and issue a pull request (versus the mails >> > with patches we get now) >> > - Hg repo works over https (which is easier to get going than SSH and >> > uses a port that is unlikely to be blocked by enterprise firewalls) >> > - Nicer online code browsing interface (whole Bitbucket interface is >> > clean and simple) >> > - Nice features like follow commits via RSS, of follow on Bitbucket >> > - Might attract even more developers, as Bitbucket is a social coding >> > site. >> > >> > The static web pages, issue tracker, and downloadable artifacts can >> > all remain at SourceForge. Downloads could be offered both at SF and >> > Bitbucket. >> > >> > I have already made a fork that is on BitBucket to try stuff out: >> > https://bitbucket.org/ecommandeur/gwt-openlayers >> > >> > We might want to make a user gwtopenmaps on bitbucket and place >> > gwt-openlayers under that user. If everybody (at least al admins) >> > agree, then I will do that. >> > >> > Greetings, >> > Edwin Commandeur >> > >> > >> > ------------------------------------------------------------------------------ >> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio >> > XE: >> > Pinpoint memory and threading errors before they happen. >> > Find and fix more than 250 security defects in the development cycle. >> > Locate bottlenecks in serial and parallel code that limit performance. >> > http://p.sf.net/sfu/intel-dev2devfeb >> > _______________________________________________ >> > Gwt-openlayers-devl mailing list >> > Gwt...@li... >> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl >> > >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> Gwt-openlayers-devl mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
