On Fri, Dec 8, 2017 at 10:13 AM, Hans HESPEN <hans.hespen_at_caduciel.com>
wrote:
> Dear Paul & Johan,
>
>
> thank you for your reply. Indeed, 4 eyes principle is like Paul says.
>
>
> The 4 eyes-principle is known for important decisions. Some decisions
> can't be made by a single person, and need to be made by two persons, for
> instance a CEO and the CFO. Launching a nuclear missile needs, apart from a
> lot of other hassle, the synchronous turning of two keys (at least in the
> James Bond movies).
>
>
> The same idea, coming from industrialisation processes in Japan, exists
> for code. The idea here is not that the committing is of that high
> importance. The basic reason here is the easy human failure where you tend
> to overlook your own errors. Just as you tend to overlook your writing
> errors in a letter. It's not that I can't write English, and committed code
> of course does compile, but didn't you forget to free a used object? You
> did some copy/paste in code and you forgot to rename an object.
>
>
> Of course, there is also an element of security. I worked for a lot of
> high security customers already, where you don't want backdoors being built
> in, for instance. At last, but not least, it's also an opportunity for
> learning when a fellow programmer can show you some techniques or show a
> different approach.
>
>
> Of course, it could be possible to not commit into svn at all, create a
> patch that's being sent to the head-programmer, who verifies and merges.
>
>
> That's not handy. I want an oversight of all commit's waiting for
> validation. It needs to be known that some commit is waiting, that some
> task is being done. I want, as a programmer myself also to be able
> to commit my code. It's when it is in the server that I can close my task
> and that my code is safe. But if you can not enforce it, then people don't
> do it, or they feel put into a corner, being labeled as a bad programmer.
> Whereas this is entirely not the case. I forgot recently to uncomment a
> where-clause, although I develop for the past twenty+ years.
>
>
> Anyway, Paul has put me on the line of code review tools, post and
> pre-commit. Tools like RhodeCode, Crucible, Rietveld, Collaborator. This is
> actually a bit too much for what I was looking for, but this might be a
> very good alternative. I will look further into them.
>
>
>
If enforced code review policies are your top priority then you should
consider using Git with Gerrit as your server, rather than Subversion. You
have already been pointed to several good tools that provide code review
options with Subversion, however, I do not believe there is going to be any
Subversion-based solution available today that can offer a code review
workflow that is as productive and easy to use as what you can get using
Git. I happen to think Gerrit offers the best option for this, but there
are certainly others.
I think Subversion has many compelling strengths for why it is a good
version control choice in general, so it just depends what your top
priorities are. You can absolutely do code review with Subversion, I just
do not believe the workflow for doing so is nearly as productive as it is
when using Git. So if you are going to choose Subversion, typically it
would be due to other areas where Subversion has strengths that Git does
not, such as path-based permissions, handling of large binaries, partial
tree checkouts etc.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2017-12-08 16:51:14 CET