From: Isidor Z. <mi...@qu...> - 2010-06-17 23:43:00
|
> But by FAR the bulk of the MinGW/MSYS > corpus is "maintained" as "here's a tarball including upstream src, some > patches, and a build script". > Well, I often have to deploy software packages to RPM platforms, and I found it very convenient to manage the unpatched/patched upstream source trees in a repo so I can avoid manual rediffing. Since I switched to that approach, I can sync up with upstream changes much more often because it is usually almost zero effort to do so. However, I wouldn't have thought of that approach when using CVS because it doesn't exactly scale well. So I wouldn't say a packaging project cannot profit from a technically superior VCS. > So...how much benefit will we get by migrating that tiny portion of the > corpus from CVS to anything else? > Ideas on how to use existing technology to improve processes usually come after working with the technology for some time. See above for one example on how I found it useful for packaging. In another post, you mentioned that msysgit is actually a msys distribution on its own. So there seems to be a community need to adapt msys. If it was using a distributed VCS, the most common way for people to do so would be to clone the repo and make their changes on their copy. Mingw could then pull their changes and cherry-pick. If I'm not missing something, improving mingw through changes from such external efforts is harder with the current maintenance approach. I think the point here is not that using better tools could not bring much improvement. We simply can't tell before someone tried it. I think the relevant point is simply the effort needed to do a switch. > > True, people are always good at working around tool > > deficiencies. However, it doesn't necessarily mean that not having > > to do so is a disadvantage. > > It's a lot of effort to accurately migrate a VCS while preserving > history A lot of effort, consisting of one line of code starting with "git cvsimport..." > > > Don't get me wrong, though. I have no objections against a > > pragmatic decision in favour of one option after thinking through the > > alternatives. I'm just opposed to "we always lived in caves, so > > there can't be anything better" logic. > > Sure. CVS sucks. Wave a magic wand and instantly convert everything to > git or svn or whatever, with full history support, See above. > AND instantly provide > a nice mingw-get-compatible set of packages for msys ports of that VCS > client and all of its depedencies...wonderful. > The code seems to be already there, in msysgit. I don't know much about mingw-get so I can't tell what exactly is missing. > But I don't have a magic wand. > > It comes down to available manpower and time. The core devs are tapped > out; look how long it's taking to get mingw-get out the door -- and even > there, we have a mega-thread from non-core-devs about writing python > scripts to install msys/mingw "in the interim until mingw-get is ready" > -- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity. > Agreed. But I think it's a chicken-egg problem. Once a convenient infrastructure consisting of binary deployment software and a distributed VCS is in place, it is probably easy enough to work on own adaptions in a way reasonably compatible to what official mingw does so more of these adaptions can be contributed back easily. Best regards, Isidor |