4.2 release
Created by: dzaporozhets
I'm done with new features for GitLab v4.2.
We'll create a 4-2-stable branch and release 4.2 at February 22.
Currently I'm working now on GitLab 5.0 without gitolite.
Activity
Created by: YenZi
Sounds like a huge change. Therefore it also sounds a bit scary to me. Gitolite has been proved to be working solid. And gitlab (in combination with gitolite) works solid for us too. So my main questions are :
- Will there be a proper migration path ?
- Will there be a configurable choice for users to either use gitolite or gitlab-shell ?
- When will gitlab 5.0 be released ? I think next are 4.2 in Feb. and 4.3 in March, right ?
I am just afraid to run into big trouble when switching this essential part of the system to something completely unknown (at least for me). I am just a bit nervous about this change but I am not saying "Don't do that" ;-)
By Administrator on 2013-02-05T09:50:51 (imported from GitLab)
Created by: dzaporozhets
GitLab 5.0 will be at March 22. We will not be compatible with gitolite. I will make a proper migration for existing users. I agree that gitolite is a solid solution. But gitolite has some disadvantages in combination with GitLab.
Some of them:
- Its a really hard to keep sync between GitLab and gitolite
- On big number of repos ( > 2000) creating a new repo, key, etc is really slow.
- When one user creates repo another one wait cause of lock with gitolite-admin
- A lot of code for parsing, pulling, pushing gitolite-admin config and keys
I understand its a huge change but its also an evolution of GitLab.
- simplier setup
- less dependencies
- increase of perfomance
Since I finish with
gitlab-shellI made a migration of my servers and write a migration manual.By Administrator on 2013-02-05T10:15:09 (imported from GitLab)
Created by: sriharshav
Most of the permission hassles will be resolved if gitlab-shell can take out need for gitlab user. I feel decision to have only one user (git) is a major move towards simplifying setup. Very welcome change indeed.
While I understand that gitolite does lots of parsing, perl helps in doing them at amazing speed. But if a solution is avoiding that lock I guess that can improve performance to some extent but can't hope to be a leap difference.
And I wish gitolite-shell will use config syntax of gitolite.
By Administrator on 2013-02-05T11:59:51 (imported from GitLab)
Created by: brodock
it may worth mention, Gitorious already have their own substitute for "gitolite", in fact, it's a ruby script that deals with what you are creating.
Have you considered using a ruby solution (that can be integrated to the application logic/database) ?
By Administrator on 2013-02-06T23:07:10 (imported from GitLab)
Created by: riyad
@randx Have you had a look at http://www.pogoapp.com/blog/posts/replacing-gitolite-with-a-redis-backed-git-server and the Gist ?
By Administrator on 2013-02-07T00:11:01 (imported from GitLab)
Created by: dzaporozhets
@Riyad I dont want to patch openssh
By Administrator on 2013-02-07T08:31:20 (imported from GitLab)
Created by: dzaporozhets
@Riyad but thanks for good links :)
By Administrator on 2013-02-07T08:31:40 (imported from GitLab)
Created by: Exordian
https://github.com/gitlabhq/gitlabhq/commit/970f86077adf2857ac3b3c1d7b0dc366a39f41f3
is 4.2 already released?
By Administrator on 2013-02-11T09:12:55 (imported from GitLab)
Created by: dzaporozhets
@chopmann 5.0pre with setup docs already in master. I'm in progress with migration script (https://github.com/gitlabhq/gitlabhq/wiki/From-4.2-to-5.0)
By Administrator on 2013-02-11T13:12:39 (imported from GitLab)
Created by: Razer6
It's here and beautiful. @Riyad Please close
By Administrator on 2013-02-23T00:23:44 (imported from GitLab)
