On 4/30/2014 21:34, Rodny Spillig wrote: >> >> Because it was a pain to track down patches applied to other branches >> and reapply it again and again, cherry-pick is god sent. Not to mention >> merging is quick and simple. It is also far far easier to do a long term >> private branch in git than in SVN, not to mention, multi-part commit >> patches are nice. > > SVN does all of that easily. Are you sure you aren't just using it wrong? > The notion that it does not branch and merge is very outdated. There is even > a whole section in the manual called "Cherry Picking". >
Does SVN allow you to manage a local-only branch that allow merging from multiple remotes? > As far as long term branches, how is "svn merge ^/trunk" any different than > "git pull" ? > Will SVN allow change tracking of said branch if it is never committed to the server? >>> How will you handle all the various things that you currently distribute? >>> You have a lot of stuff in your repository, and it all works nicely because >>> of how svn treats each directory as essentially a separate repo. What are >>> you going to do about the branches, tags, and experimentals? >>> >> >> Already mentioned in the original email. > > Not really. The entire workflow changes drastically, and you've not > indicated at all how users should deal with that. > I have already mentioned branches and tags are migrated, they're all there. If you haven't already noticed, git-svn migration preserves history fine. Experimentals are outdated and unused and has not seen any changes for a long time, and unlikely to see any significant changes soon. The only gem left in experimental is ironcrate, which is still far from complete, I doubt there are actually active ironcrate users. >>> Have you even considered other distributed systems? Mercurial, Bazaar? Or >>> is it git all the way just because it's git? Git is much more of a "Do >>> what Linus says" project, than it is a tool that's solving a problem. >>> >> >> What does Linus have to do with the decision? If anything, I'll use it >> because Linus recommends it. > > You ignored the question, which implies the answer is no. > I can reply with the same rhetoric, why choose Mercurial or Bazaar over git when they have roughly the same functionality? Do you actually know any command-line phobic end users that want to download mingw-w64 and build gcc and binutils from source to benefit from the supposedly more user friendly GUI frontends others have? Does Linus using git somehow cause it to be a bad choice? We chose git because it is far more familiar to the bulk of our contributors, namely the ReactOS and Wine developers. Some contributors are already using their own git band-aid over SVN. None of our developers have even mentioned Mercurial over the years. Bazaar is out of the question because SF doesn't have that option. >>> I'd actually like to see you move to a more recent version of svn that has >>> a lot of new whiz-bang features that make it more desirable to stay with >>> the status quo. Contrary to popular belief, git doesn't merge/branch any >>> better than svn, unless you compare brand new git to svn v1.0. >>> >>> Finally... why not just set up a git mirror like so many other projects do? >>> >> >> Because git commits cannot easily push back to SVN, and great, you have >> all the power of git and the inconvenience of SVN. > > SVN seems to be an inconvenience to you because you aren't using it > correctly. That's not a deficiency in the tool. And as pointed out, many > projects successfully use a git mirror, including GCC itself. > If you're going to work on the existing SVN WC anyway, why setup an online git mirror in the first place? What is the benefit of setting up a read-only DVCS that can only pull from a single source? > Your original message said that the project "may" switch to git. I now > understand that this was not true. It should have said that the project > "will" switch, and you are entertaining zero other options. Why even bother > asking your community? Why not just tell instead of ask? Your responses > reek of Keith Marshall. This is the kind of thing that drove us away from > mingw.org in the first place. This is not what we have come to expect over > the years. > "May" here hinges on the amount of migration effort required, which was surprisingly light. So yes, it is now a definitive "will". For the record, I have no idea what Keith did to you (what exactly did he do anyway?) to even bring him up in this conversation. Are you saying you moved just because some source code repo was shifted to another VCS you disagreed with?
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
