Hi,

Given that Gitb is a "distributed control" system, I think you should review 
points 1 and 2 because they try to re-inforce a centralised control system. And 
then pass off the responsibility to a machine.

It's much better if responsibility stays with the human (see the `git help 
workflows` man page, `tutorials` page, user-manual and especially 
https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows). Ideally 
you should be enabling the devs so that they can build and test their code 
automatically without needing special permissions (i.e. pre-review). This then 
should mean that the devs bring better working tested code to the reviews.

All the old style config management approaches(*) are simply a statement of 
failure to appreciate the world has moved on. We now have perfect instant 
replication. Config management was about protecting the one and only 
irreplaceable master copy (Picasso, Dali, Titanic's ship plans, whatever). Now 
it is about verifying that you have the right copy (as given by the sha1 in 
Git). It is a hard lesson to unlearn.

<steps off high horse>

regards

Philip
(*) all the old CM practices are based on Drawing office practices from the 
late 19th / early 20th century when the Titanic was young and it was 'the 
master drawing' that was king and had to be protected. Coputing has completely 
and utterly undermined the basis for those rules.
  ----- Original Message ----- 
  From: AutoKhan 
  To: Git for human beings 
  Sent: Thursday, August 25, 2016 6:11 PM
  Subject: [git-users] gitlab CE vs gitlab EE vs bitbucket (on-prem) or 
something else


  Hello everyone, I am doing a comparison of the above mentioned servers for 
on-prem deployment. I would appreciate any feedback.

  With any of these tools, we will be using Git not Mercurial.

  Gitlab Community vs Bitbucket vs Gitlab Enterprise OR if another system is 
better than these




  What is important: 

    1.. pull requests: would like to kick off build based on approval of code 
review

    2.. branch permissions: we want to disable direct commit to master branch. 
we do not want devA to be able to modify branch created by devB (not a deal 
breaker if unavailable)

    3.. conditions: merge to master will only be allowed once code review has 
passed This means another user/dev/tester has OK'd the pull request. Or another 
mechanism for this function.

    4.. Nice UI

    5.. multi-site HA

  Thanks


  -- 
  You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.
  To unsubscribe from this group and stop receiving emails from it, send an 
email to git-users+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to