Anyone can checkout or clone our codebase, patch it and choose not to submit the patches back to the community - no matter which publicly available VCS we use. I don't see that the choice of VCS should affect that; the driver to submit patches to the official project is that you don't want to keep maintaining your own/local bugfix for subsequent releases.
For myself, I just want a simpler way of working than I can have with SVN. The more I have to depend on network connectivity for simple things like a revision history, diffing two revisions etc., the more I tend to consider the tooling choice a problem rather than an asset. For example, I would like to test out two different approaches to solving a refactoring in one of our plugins - and since I build on several boxes (using seveal OSs), I would like the simplicity of local branching and cloning, making it trivial to sync changes between the boxes without having to checkin my experimentation to the central SVN server until I am done. Having to take the pains of creating [several] SVN remote branches is impractical here, particularly with the diff/merge/sync pains of SVN. While it is doable to perform a Git or Mercurial client clone of a Subversion repository, the integration works well only for pulls. Several problems/bugs/inconsistencies become apparent when attempting to push back changes into SVN from a locally available Mercurial or Git branch, for instance. This implies one cannot seamlessly use the advantages of the DVCS when working against SVN on the server side. ... so my 2 cents say that a DVCS mirror or migration is purely an advantage. We are not moving the codebase away from the Codehaus fold, but simply improving our tooling. 2013/6/28 Robert Scholte <[email protected]> > Yes ,I have these same concerns as Mark. > > Of all the Maven related projects which have been moved from SVN to GIT I > haven't seen more patches then before. So I'm not sure if this will > increase the number of contributions. > Don't get me wrong: I do understand the advantages of GIT, but especially > the cloning part makes it a lot easier to maintain your own version (you > don't depend on one of the plugin maintainers to approve patches, if any is > still alive). > > Robert > > > On Fri, 28 Jun 2013 16:55:52 +0200, Mark Struberg <[email protected]> > wrote: > > >> >> There were some projects which moved to GIT. >> >> But after a short while they are now all DEAD! >> >> This has nothing to do with GIT itself (which I love), but with the >> missing 'ownership'. >> It's totally easy on github to just fork a project and fix your bug there >> - fully agree! >> But what about merging this stuff back? Well, this just does not happen >> most of the time. >> >> And this is the reason why I still love to have those projects over here >> at codehaus, eclipse or apache. >> >> Mostly because all people then know where to get the origin from. >> >> Again, this has nothing to do with GIT vs SVN. It just has to do with >> having some 'cannonical' source or not. >> >> LieGrue, >> strub >> >> >> >> >> ______________________________**__ >>> From: Jochen Wiedmann <[email protected]> >>> To: [email protected] >>> Sent: Friday, 28 June 2013, 16:07 >>> Subject: Re: [mojo-dev] Re: Mojo GIT migration or mirroring? >>> >>> >>> >>> Just asking: Does Github offer to provide an SVN mirror? Or is there any >>> other way to have a mirror without too much hazzle? >>> >>> >>> >>> >>> >>> On Fri, Jun 28, 2013 at 9:50 AM, Fred Cooke <[email protected]> >>> wrote: >>> >>> >>> >>>> >>>> For GIT users there are several ways to work with SVN, so that's >>>>> probably why this isn't that urgent. >>>>> >>>>> >>>> That's not really a good reason not to, because: >>>> >>>> * The SVN >> Git process isn't fast (because SVN is itself SLOW) >>>> * Each converter has to find motivation to bother setting this up >>>> and doing it in the first place. (read, they'll just not bother most of the >>>> time) >>>> >>>> * Each conversion will have a different set of hashes even if the >>>> other parameters are the same and thus won't be able to be collaborated >>>> between effectively. Having a single official mirror means others can >>>> effectively work together on "it" with the final result pulled back into >>>> SVN when ready and then automatically pushed back to Git again. The work >>>> flow is a pain, but still a lot better than suffering SVN in the first >>>> place. >>>> >>>> migrate > 1 official mirror (per mojo) > N unofficial mirrors/leave it >>>> alone >>>> >>>> I'm not ignoring the work involved in mirroring, just pointing out some >>>> facts. I don't think the Maven tool-set / infrastructure is 100% ready for >>>> Git, to be perfectly honest. The sink or swim method may be a good way to >>>> get it there, but might be painful, too. I'd certainly appreciate more Git >>>> friendly behaviour, though :-) >>>> >>>> Fred. >>>> >>>> Robert >>>> >>>>> >>>>> >>>>> On Thu, 27 Jun 2013 21:44:33 +0200, Lennart Jörelid < >>>>> [email protected]> wrote: >>>>> >>>>> >>>>> Folks... if anyone has an answer to this question, I would be all ears. >>>>> >>>>>> Can I work with GIT or Mercurial here? Onto some mirror? >>>>>> If not - is there a process to distribute projects/plugins to GitHub? >>>>>> >>>>>> >>>>>> 2013/6/25 Lennart Jörelid <[email protected]> >>>>>> >>>>>> >>>>>> Hello all, >>>>>> >>>>>>> >>>>>>> I wonder if the Mojo project has a structured way of migrating to a >>>>>>> distributed VCS (GIT, presumably, or Mercurial) for various currently >>>>>>> SVN-based projects - or any policy on a 2-way mirroring between the >>>>>>> two >>>>>>> VCS'es. >>>>>>> >>>>>>> I believe distributed VCSs increase visibility and reduce complexity >>>>>>> for >>>>>>> donning a patch compared to the standard subversion way, >>>>>>> particularly with >>>>>>> the help of processes and services such as GitHub or BitBucket. >>>>>>> Anything >>>>>>> that can increase visibility and reduce hinders in contributing >>>>>>> patches to >>>>>>> projects is in itself a Good Thing. >>>>>>> >>>>>>> So ... is there a Git/Mercurial mirror or migration process for SVN >>>>>>> projects at Codehaus? >>>>>>> If so - where can I find access details? >>>>>>> If not - why? >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> +=============================**=+ >>>>>>> | Bästa hälsningar, >>>>>>> | [sw. "Best regards"] >>>>>>> | >>>>>>> | Lennart Jörelid >>>>>>> | EAI Architect & Integrator >>>>>>> | >>>>>>> | jGuru Europe AB >>>>>>> | Mölnlycke - Kista >>>>>>> | >>>>>>> | Email: [email protected] >>>>>>> | URL: www.jguru.se >>>>>>> | Phone >>>>>>> | (skype): jgurueurope >>>>>>> | (intl): +46 708 507 603 >>>>>>> | (domestic): 0708 - 507 603 >>>>>>> +=============================**=+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> -- >>>>> >>>>> Using Opera's revolutionary email client: http://www.opera.com/mail/ >> >>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe from this list, please visit: >>>>> >>>>> >>>>> http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> "That's what prayers are ... it's frightened people trying to make >>> friends with the bully!" >>> >>> Terry Pratchett. The Last Hero >>> >>> >>> >>> >>> >> ------------------------------**------------------------------**--------- >> To unsubscribe from this list, please visit: >> >> >> http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email> >> >> >> > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > > ------------------------------**------------------------------**--------- > To unsubscribe from this list, please visit: > > > http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email> > > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: [email protected] | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
