Support for new version gitolite v3
Closed
Support for new version gitolite v3
Created by: shurco
Can I upgrade to a newer version gitolite 3 ?
Created by: renebakx
I guess you could always try to upgrade and revert if it fails.
Looking at this http://sitaramc.github.com/gitolite/dev-status.html and if the way configs are written it should work out of the box. However.. besides the newer version what is the gain of upgrading to V3? That's a serious question, cause if the answer is something like better performance or something like that. I'am going to upgrade to ;)
By Administrator on 2012-04-30T10:19:22 (imported from GitLab project)
Created by: wingrunr21
I have not updated my personal test gitolite install to v3 but there were very little changes from the gitolite.conf side. The gitolite gem should still work fine. If you find issues, please file them.
http://www.github.com/wingrunr21/gitolite/issues
By Administrator on 2012-05-17T21:16:33 (imported from GitLab project)
Created by: sroth80021
from what I can tell, the main benefits of Gitolite v3 are:
- cleaner integration with other authentication options (besides ssh keys) such as:
- smart http
- ldap
- ability to use LDAP groups for authorization rules (everyone in this org can see this repo, for example)
- ability to easily close the repositories -- for backups/maintenance, for example.
- v2 is in support mode (no new features, etc)
I think given how extensible gitolite is, all of this was possible with v2, its just that these use-cases are now better documented/mainstream as opposed to going down the custom integration path.
By Administrator on 2012-08-26T04:35:53 (imported from GitLab project)
- cleaner integration with other authentication options (besides ssh keys) such as:
Created by: sroth80021
FWIW, I've done some initial testing with Gitolite3 in a new install, and I dont see any major issues-- I can create users, register keys, add users to projects, push code, etc. So far I actually havent seen any differences in behavior as compared to gitolite v2.
Important note: my comparison is with the yum-installed gitolite v2.3.1-1.el6 (rh6) as opposed to the one in the gitlab repo.
By Administrator on 2012-08-27T21:21:11 (imported from GitLab project)
Created by: ldath
I'm not 100% percent sure but I think that started from gitolite v3 there is option to have group of users and group of repos
Example 1.
@myrepos = foo @myrepos = bar repo @myrepos RW = aliceExample 2.
repo gitolite tsh gitpod RW+ = sitaram RW dev = alice bob R = @all@all in last example is probably public repository for READ. I'm not sure about group of users but grouping project should be possible.
In big sets of projects this can be handy.
Sorry about my Bad English
By Administrator on 2012-08-28T20:18:54 (imported from GitLab project)
Created by: sroth80021
Yeah, the @all group is a really nice capability. From a few posts, it seems it existed in v2 (at least the @all group), but its much better documented in v3 -- see http://sitaramc.github.com/gitolite/g2/rc.html and search for @all
By Administrator on 2012-08-28T20:36:49 (imported from GitLab project)
Created by: sroth80021
I've just created issue 1321 for having gitlab support for the @ all gitolite group. I split it out into a separate issue, since the @ all group existed in gitolite v2 and so the decision to support @ all is independent of the decision to move to gitolite v3
https://github.com/gitlabhq/gitlabhq/issues/1321
By Administrator on 2012-08-28T20:47:11 (imported from GitLab project)
Created by: ldath
To be more exact @all mean only All users with accounts and keys in gitolite. This note make repo fully public. It makes repo public for registered users. Is good for example libraries public for all developers in company ecosystem.
By Administrator on 2012-08-29T09:49:24 (imported from GitLab project)
Created by: dzaporozhets
Hey guys. I've created v3.04 branch in our fork and updated docs (ad3a88cf). Now g3 is default for fresh setup
By Administrator on 2012-09-09T17:25:05 (imported from GitLab project)
