@Frans ??
Sorry, thought we were discussing moving from svn, and you brought up arguments that moving away from svn to git will create new problems (around code quality process) and at the same time arguing that git does not really improve things that much. We pose counter arguments and you respond like this??????? It is more like we who should be offended, you think we have no experience with svn or that we are using it wrong etc. The problem of local performance when doing "svn update" (it can takes minutes) is a problem my current team has suffered for months, now a little better with SSDs disks, we even optimized our dir structure to improve performance, this problem is well known and talked about in svn mailing list (they plan to change local storage to single .svn dir in 1.7 for this reason). I have thought I would bring up more concrete arguments about svn tree conflicts but I think it seems pointless, you will probably be more angry or offended somehow... /Torkel On 5 Nov, 10:38, "Frans Bouma" <[email protected]> wrote: > Enough. > > > @Frans - > > 1. SVN is noticeably slower even on local gigabit subnet. Even on local > > computer. > > Why? when the codebase is non trivial, every "svn up" on the root first > > traverse the local working copy of ".svn" folders. At work I have a repo > > where it can take ~1 minute. on 4core machine. with the working copy on SSD. > > gee, so it must suck dogballs everywhere, right? More anecdotical > evidence: I don't see the slowness you're seeing. (and our repositories are > not small). But I must be a lying dumbass who has no clue what the f*ck he's > talking about, right? That's the biggest f*cking problem with this and the > other NH mailinglist: everytime you try to do a debate about something > related to software engineering (read: SERIOUS debate), it quickly derails > into dumb-ass bickering land because moaning about irrelevant details is much > more fun and more importantly: it moves the focus away from a real problem. > "Oh look, shiny things!" > > If you're so f*cking briliant why can't you convince everyone github > is heaven and every second NH isn't up there it's the biggest f*cking problem > on earth? This whole week this debate is ongoing, but ... what happens? Not > single soul is taking a decision. There's not even a debate on arguments. > What happens instead is that that all energy is put into convincing me how > SVN sucks in every possible way. Ken, I don't really give a f*ck. If you > think I can't think for myself and I need convincing about what scm is better > you're even a bigger fool than your email suggested. More importantly, if you > thought my post was about which f*cking scm is better you are also as stupid > as your email suggested. My email was about code reviews and which _process_ > (guided by the scm) fits better. That it was interpreted as "look! this guy > thinks SVN is great. haha, let's tell him how wrong he is"... incredible. > > > I work using git-svn which at least take that pain away. Merging is still a > > bitch. > > merging will always be a problem with code edited in both sides. > Everyone who says git will automagically solve that for you, lies. > > But whatever, do what the f*ck you want. > > > 2. As for "move files through the Repo not the WC" - this is steve jobs > > saying "you're holding it wrong". > > A guy wondered why I don't have much problems with svn. I try to > explain things. And here he is, moron Egozi who tries to be the comedian. Let > me bash it into your thick empty skull: I was wondering about code review > processes. I wasn't wondering why you and your fellow git lovers couldn't see > the golden shine emitted by subversion. I wasn't wondering why you and your > fellow git lovers didn't adore SVN, as that wasn't the point. > > Anyway, enough. Like Gregory said: "I don't need this bickering", and > he's right. So long. > > FB > > > > > > > > > > > On Fri, Nov 5, 2010 at 10:46 AM, Frans Bouma <[email protected]> wrote: > > > > > 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 > > > -- > > Ken Egozi. > >http://www.kenegozi.com/blog > >http://www.delver.com > >http://www.musicglue.com > >http://www.castleproject.org > >http://www.idcc.co.il- הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם
