Menu
▾
▴
Re: [Gwt-openlayers-devl] moving to Bitbucket
|
From: Andrew H. <ahh...@gm...> - 2011-02-14 23:15:10
|
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-presenter/source/checkout> http://code.google.com/p/gwt-platform/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 > |
