4 eyes priciple on subversion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: 4 eyes priciple on subversion

Johan Corveleyn-3
On Fri, Dec 8, 2017 at 10:58 AM, Hans HESPEN <[hidden email]> wrote:

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

--
Johan
Reply | Threaded
Open this post in threaded view
|

Re: 4 eyes priciple on subversion

Paul Hammant-3
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 
Reply | Threaded
Open this post in threaded view
|

Re: 4 eyes priciple on subversion

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 <[hidden email]>
Sent: Friday, December 8, 2017 12:51:38 PM
To: Johan Corveleyn
Cc: Hans HESPEN; [hidden email]
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 
Reply | Threaded
Open this post in threaded view
|

Re: 4 eyes priciple on subversion

Stefan Sperling-9
On Fri, Dec 08, 2017 at 03:13:41PM +0000, Hans HESPEN wrote:
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 4 eyes priciple on subversion

Mark Phippard-3
In reply to this post by Hans HESPEN
On Fri, Dec 8, 2017 at 10:13 AM, Hans HESPEN <[hidden email]> 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.

--