Wow, I really have been away for a long time. I found this thread while cleaning things out now that my 578493578943 projects at work are finally finishing. Also, I'm trying to see if we can incorporate winpthreads in one project :)
I have to say, this is kind of sad, mostly because of 1) misinformation and 2) negative treatment toward a user with a different opinion. I'll address a little of (1) down below. For (2)... Jon, why so angry? If you have good technical reasons for proposing a switch to git, you should be able to present them cogently, ideally from the standpoint of "We need to solve problem X; here's my solution.", and they should easily stand on their own merit. Users are allowed to be dicks.. they're users. Be nice in return. Kai taught me that a looooong time ago. Some German idiom about not plucking chickens before they hatch or something.... I dunno. On Wed, Apr 30, 2014 at 2:05 PM, JonY <jo...@users.sourceforge.net> wrote: > 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? The big problem here that git might actually fix is that nobody ever used svn correctly, despite my requests. I posted a very long email to the developer list back in 2011 that basically said "don't manually patch files, use svn merge before making edits." Search the list for subject "Proper merging of patches", 8/7/11. I was aggressively shot down by both Ozkan and Kai, who vehemently defended the notion that we should never use the merge capabilities of the version control software. That's the primary reason why patches between branches are impossible to tie together. Fixing this would be great. If switching to git makes people finally keep accurate merge metadata, then that is a pretty good thing. But to be clear, the current difficulty in tracking down patches and applying them elsewhere is a facet of how we chose to misuse svn, not the tool itself. We use svn where I work, and we branch and merge all day long. It's wonderfully easy to do. It does require a net connection, but for our purposes, that's fine. Besides, I'd rather push my work to a server, given how many laptops I broke this past year :) >>>> 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. I was about to change a few things in experimental, actually, because I got a nagging email that buildbot can't handle the binutils switch from git to cvs. Although I question whether anyone actually needs buildbot anymore. This change will equally break buildbot, so I may just shut it down. I don't really maintain it, haven't seen Mook log in in a while, and I'm not really part of this project anymore (or haven't been in a long time, and probably haven't been missed). Other than that, the buildroot makefile is in there, which though being out of date is still referenced in a lot of places. And it's used by buildbot. It should likewise be updated or removed, pending what happens to buildbot. I'll send a separate email for that. > 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. ReactOS uses SVN, not git. They even have svn posting to their IRC, like we used to have with CIA. Maybe they use both? This page says svn, tho: http://www.reactos.org/development/source-control I looked back through a month or so of IRC logs. It looks like this whole thing was a spur of the moment off the cuff thing from you, Jon, where you were complaining about your cherry picking endeavor, opined about git, and Kai asked you to post this message. I didn't find anything before that going back through March. So it doesn't seem like a "we chose git because...", more like a knee-jerk reaction that a number of people on the project seem to like after-the-fact. Sometimes good things come from a proverbial "impulse buy". Maybe this is one such thing. I certainly hope so, since it really seems to not have any forethought at all. I'm not saying that to offend you, Jon, but it really does seem like that's the case. > 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? git mirrors mainly benefit people that are maintaining their own branches, and probably won't contribute back to the project. It probably doesn't apply here. And even if it did, I would not think that we (can I still say "we"?) would want to encourage private forks :) Now... that said, there's a few things that I didn't see addressed anywhere in this thread. 1) Jon, you had asked me to setup a mailing list for svn commits. I did so. Then SF added their own thing that just sends the commit message without the patch in the body. So now we have both. What is your plan with doing that for git? Are you going to still email messages to a list? Are you going to do it per commit, or per merge? Binutils recently tackled this same question, and they settled on 1 email per commit. Also, would you only want emails on a certain branch? 2) Seeing as how it just came up on the mingw list, how does authenticity verification of changes happen when someone wants to merge in a big change? On said list, people made the claim that this project doesn't check that commits are legally safe. Under svn, every change gets checked by someone before it is committed. What will be the new procedure, if a person has a giant blob to merge in? Admittedly, the problem is still there in svn (like that time you merged in the vista headers... lol :) but it's more common under git, I think. Consider putting some thought into how you will accept large changes from a "was this copied from proprietary sources?" standpoint. 3) svn history is impossible to change. git history is purposely malleable, usually so that a user can merge a clean branch without all the false starts that come from development. How will you stop users from (possibly inadvertently) changing the history of whatever "trunk" becomes in an undesirable way? Maybe it's a non-issue? I don't expect malice, but I could easily see a user accidentally doing that. I've done it myself, actually, on two occasions, the first of which required a restore-from-backup (oops..). 4) How does the release process change as documented here: http://sourceforge.net/apps/trac/mingw-w64/wiki/VersionSpec 5) This is kind of a pie-in-the-sky thing, but is it at all possible to keep an svn mirror of the git repo, so that all those many links out there in the wild still work? Might be nice, probably not possible. Oh well. 6) Is there any way to do a partial checkout with git? Right now, someone can check out just a small piece of the whole repo, whatever is interesting. How do you do that in git? I have only ever been able to figure out how to do the whole thing. On one project that I'm on, the svn repo is a few terabytes. That's a blocker for that project switching to git -- it doesn't scale well at all. If you know how to deal with that, I'd be interested. The only answer we've ever found was "split it into many repos", which obviously isn't a viable solution or we would have done it already. Anyway, those are my questions. Obviously I'm just an outsider at this point, so feel free to ignore the whole email if you want. I mainly felt compelled to read the thread because completely coincidentally, another project I'm on is switching from a very old system to git, and doing it very poorly. Then, of course, after reading, I saw that the primary reason has to do with a concern I raised 3 years ago...... But anyway, take it all for what it's worth -- just another email in the inbox. Have fun, happy hacking. ------------------------------------------------------------------------------ "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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
