Bill Hacker wrote: >> I can't run a patch and work on a different issue >> myself - I'll mix both. Or I'll have to check out into another tree and >> lose the patch. > Indeed. And have to go find it and manually re-apply, and/or alter and > re-apply 'coz it no longer fits quite tha same on code that has moved on > in other details.
And once you've applied it, it is mixed with your existing changes. That's the main problem. > But unless and until the patch is vetted and accepted into the > mainstream that is exactly what a 'production' user wants. A production user doesn't want patches or something else. He wants working binaries. > As said - developers and production users have different priorities and > CVS is a fairly effective compromise - ELSE it would have been scrapped > long ago by a lot more projects than have done so to date. No, that's not true. It's just that developers are lazy and don't want to learn new, potentially better tools. They are also conservative and don't want to change one tool for the other without real benefit. Several projects did the mistake to convert from cvs to svn, which didn't really improve productivity (I guess). >>> Rather than 'nag' - set up what you want and see who joins or lends a >>> hand. >> It is really cumbersome to keep any repo synchronized, especially if you >> want to have a nice repo which reflects vendor branches correctly. > Understood. But *any* repo and any toolset needs effort. No doubt. The differences, however, are orders of magnitude. >> Basically all manual CVS interference has to be dealt with either in the >> tool or manually. > Alternatives may provide more comfortable knobs and buttons - but AFAIK, > none of them yet read minds, let alone cover the sharp edges. Oh yes, they do cover sharp edges. They might have other, different ones, but not as many and not as sharp (I'm obviously biased). > But if your peer contributors - who must have nearly identical concerns > - don't yet see CVS as a target for 'real soon now' replacement, there > must not (yet) be an overwhelming case for change. Oh yes, everybody who EVER tried adding third party software to the repo, or rather kept maintaining it, has been swearing on CVS. Even Matt decided that CVS was evil and started the whole patch thing. The patches helped on one side but are hurting on the other side - much more. The real salvation is a version control system which will help the developers in their tasks - not stand them in the way. > Change can't take place until it is possible for those involved to eval > both tools side-by-side - on DragonFly, not 'other project x' - until > they are convinced the advantage is worthwhile AND will not make it > harder in general to use. No doubt. Bear in mind that every new tool needs some effort to learn. This means that everybody involved has to accept the fact that they need to put some effort in in order to be able to fairly evaluate the tool. So a learning curve has to be expected. > I'm not defending CVS in particular. I'm just saying if *most* folks > don't see <whatever> as broken a fix won't get a lot of followers. People still program in C. People keep writing shell scripts. *Most* people don't realize the shortcomings of the tools they are using because they a) they don't reflect on their workflows and they are b) too lazy to check out alternatives to realize there is help. > .or we would have left 'C' for something else about fifteen years ago, > let alone the x86 archeologitecture. You exactly nailed the point. People don't want to move. They don't want to learn. Even if the alternative would be orders of magnitude better. cheers simon
