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 - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם
