> > 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
