Hi, On Mon, Apr 28, 2014 at 11:49 PM, Rodny <[email protected]> wrote: > JonY <jon_y@...> writes: > >> >> Hi, >> >> mingw-w64 may migrate from svn to git in the future, seeing that sf can >> now do multiple repos per project. >> >> Structure wise, everything under trunk will still stay together in the >> new repo, but any externals, /experimental/* and /web may move into its >> own repo. >> >> Discuss. > > Hello, world. First time poster, long time user. > > I know I'm in the minority, but I'd just like to say that I'm actually > against this change. We use your products in house here almost constantly > (Bob's your uncle for that!), and we really love how easy it is to use your > code base. We always build our own toolchains, and we are setup to > interface directly to you. Switching this up for no apparent reason throws > a giant wrench into our operation. With our staffing, we will be fubar > bundied for all you WW2 buffs out there. > > I noticed that everyone in this thread, including this original post, is > coming from the standpoint of "why not use git?" while I'd like to ask you > the question, "Why are you changing?" > > Ignoring the endless holy wars, some practical concerns that we have here > are the dismal support on native windows for git. TortoiseSVN makes > browsing your changes and picking the ones we want extremely easy in a > graphical environment on the platform that you're built to provide > compilers for. It just seems natural for a Windows Compiler Project to use > tools that... you know... work on windows. (Yes, I know of msysgit. My > statements stand.) > > Another practical concern -- do we now have to checkout your entire > repository just to get one revision? git lets you get All or Head. What > about the equivalent of 1234? Will you provide documentation for users > like us to adapt to this new model? Or are we stuck? > > 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? > > 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. > > 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? > > And, this is just an observation from an admitted relic in this advanced > age (been doing this for over 40 years, I'm at the end of my career now..) > this looks like a spur of the moment idea that has inadequate planning and > far reaching consequences. This is more like what a certain competitor of > yours often does -- from the hip radical change for the sake of change with > poor planning and no business case for it. That only works when running > for president (ba dum!) > > I've seen this happen many times over the decades, and the story is always > the same. I guess I'm just hopeful that people today would learn from the > mistakes of those that came before them. Or maybe the net just has no > place for an old engineer anymore. > > Obviously, like I said, this is a minority post. I realize that. And it > will probably be met with very little that's positive. But at least > understand that you have users here that aren't that vocal that would > appreciate you not jumping on the latest bandwagon.
Sorry, I am replying only because you've written your email in a way you must have realized was near guaranteed to start a flame war, which is very unlikely to be useful. There was a time, maybe 5 years ago, when it was common to assert that git was a fad and subversion was fine, but you must have noticed that that conversation died off a long time ago. I assume that you haven't used git or mercurial on a project with many distributed developers. For some reason it is very difficult to explain in the abstract why DVCS is so much better in this situation than centralized one-commit systems like svn. It only becomes clear after using these systems for a while. In case it is helpful, there's a very good explanation by Joel Spolsky (for mercurial) here: http://hginit.com/00.html See also "Distributed Version Control is here to stay, baby" http://www.joelonsoftware.com/items/2010/03/17.html Best, Matthew ------------------------------------------------------------------------------ "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
