So you're saying I should build my own manually controlled 2-bit DVCS with local SVN repos, GETs and patches? Seriously? This is to DVCS as archiving changed source files was to VCS.
And the moving part: You're right, but besides being cumbersome, that means checking in stuff that has yet to be made working. I don't like temp commits. Neither does the CI server. You're playing down some real problems. Also, you're not taking into account the social effects of a real peer system. Suddenly, everyone can participate within the system, without friction. You're no longer a 2nd class citizen until you get committer status. (OTOH, everyone who has ever participated in a DVCS-based OSS project will suddenly feel much more 2nd class around SVN now they've seen the light!) Of course, SVN is not that broken. But this is not like RDBMS vs. NoSQL hyperbole - DVCS does have most advantages on its side. Especially in an OSS environment. Good as SVN was, it's time to acknowledge that a better idea has come along. > -----Original Message----- > From: [email protected] [mailto:nhibernate- > [email protected]] On Behalf Of Frans Bouma > Sent: Friday, November 05, 2010 9:47 AM > To: [email protected] > Subject: RE: [nhibernate-development] Re: Turn on Git support in > sourceforge ? > > > > oh come on... every SCM is transactional (ok, old goo boxes > aren't > > > but who uses those?), and once committed, it's there. Rolling back > > > isn't hard though, and yes also in svn not hard :) > > > > There's no such thing as a local commit in SVN. If you're not a > committer, > > you're on your own. > > get source, checkin local svn, develop change, extract patch, > send > patch. IF you really want to. It's less ideal, if you don't get a > branch on > the central repository, true. for patches being sent, this isnt a > problem > (from the pov of the central repository). For devs working in a group > on > feature, it might. > > > > the only problem which could pop up is code merged in local repos > > > pulled from local repos which is then merged to main trunk. You > know, > > > the problem I mentioned ;). As apparently people here aren't that > > > strict, it's not something to worry about, right? > > > > It's a problem the committer has to solve if he chooses to do it. He > might > > have a good reason, like an imperfect patch he wants to fix himself > or > > integrate with something before committing the whole thing. > > > > You wouldn't give commit rights to someone you don't think can handle > this. > > In fact, dealing with a non-committer via DVCS will give you a much > better > > idea whether that person can handle the tool, because they can > actually > use > > it before they join. > > that doesn't solve problems related to changing code. Because one > can pick up a hammer and smash something doesn't make that person a > carpenter. > > FB >
