4 eyes priciple on subversion

[Hans HESPEN]

Dear Subversion enthousiasts,


apart from some issues around the use of changesets, or the use of patches, I couldn't find anything on the subject of using the 4eyes priciple with subversion.


I would hate to go through the process of stopping to work with subversion and install something new like TFS or Embarcadero's StarTeam, but I also want to start work with the 4 eytes pricniple, which is a known industrialisation technique.


Maybe we could work out something with the pre-commit hook.


I'm as much surprised about the fact that googling doesn't give me any information on 4 eyes priciple and subversion, as if I would be the first globally to want to implement it (it existed already in 2005 on StarTeam) as I'm surprised that nothing seems to exist in Subversion.


So, is there any way we can implement a 4eyes principle with Subversion.


High regards,


Hans Wendel van Hespen

software engineer architect Delphi

[Johan Corveleyn]

Post by Hans HESPEN
Dear Subversion enthousiasts,
apart from some issues around the use of changesets, or the use of patches,
I couldn't find anything on the subject of using the 4eyes priciple with
subversion.
I would hate to go through the process of stopping to work with subversion
and install something new like TFS or Embarcadero's StarTeam, but I also
want to start work with the 4 eytes pricniple, which is a known
industrialisation technique.
Maybe we could work out something with the pre-commit hook.
I'm as much surprised about the fact that googling doesn't give me any
information on 4 eyes priciple and subversion, as if I would be the first
globally to want to implement it (it existed already in 2005 on StarTeam) as
I'm surprised that nothing seems to exist in Subversion.
So, is there any way we can implement a 4eyes principle with Subversion.

Hi Hans,

Maybe you should explain concisely what the 4eyes principle is, and
how you see that fitting into the Subversion ecosystem. Just trying to
maximize your chances of getting useful suggestions, as not everyone
here knows what you mean ...

[Paul Hammant]

I think Hans means code review prior to the commit landing in branch that
other people are continually doing 'svn up' from.

If so, Rietveld, Gerrit specifically enable code review before the commit
lands. Commercial vendors such as RhodeCode an Assembla have code-review
capabilities in their larger portal experiences.

- Paul

[Hans HESPEN]

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.


Thank you so much.


High regards,


Hans Wendel van Hespen


________________________________
From: Paul Hammant <***@hammant.org>
Sent: Friday, December 8, 2017 12:51:38 PM
To: Johan Corveleyn
Cc: Hans HESPEN; ***@subversion.apache.org
Subject: Re: 4 eyes priciple on subversion

I think Hans means code review prior to the commit landing in branch that other people are continually doing 'svn up' from.

If so, Rietveld, Gerrit specifically enable code review before the commit lands. Commercial vendors such as RhodeCode an Assembla have code-review capabilities in their larger portal experiences.

- Paul

[Stefan Sperling]

Post by Hans HESPEN
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.

Perhaps add reviewboard to your list? https://www.reviewboard.org/

It offers integration with Subversion:
https://www.reviewboard.org/docs/manual/3.0/admin/configuration/repositories/subversion/
And it might be a bit more minimal than other offerings.

[Mark Phippard]

Post by Hans HESPEN
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.