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