123456789101112131415161718192021222324252627282930313233 |
- Understanding Read Only Mode of projects
- =========================================
- If a project is in Read Only Mode, the users of the project may not be
- able to modify the git repository of the project. Let's say you forked
- a project, then the forked project goes into a read only mode. You won't
- be able to modify the git repository of the forked project in that mode.
- After the read only mode is gone, you can begin to use the git repository
- again. Let's say you decide to add another user to your fork, this time
- the project will go in read only mode again but, you still will be able
- to use the git repository while the new user will have to wait for read
- only mode to get over. This is also true when you remove a user from your
- project. The removed user can still access the project's git repository,
- given that he had at least commit access, until the read only mode is over.
- In Pagure, we use gitolite for Access Control Lists when using SSH.
- Modifying gitolite may be a time taking task (depending on number of projects
- hosted on the pagure instance) that's why Pagure does it outside of HTTP
- Request-Response Cycle.
- Whenever you fork a project or add/remove a new user/group to project,
- gitolite needs to be refreshed in order to put those changes in effect
- for ssh based git usage.
- Actions that put the project in read only mode
- ----------------------------------------------
- All the actions that needs gitolite to be compiled, will bring the
- project in read only mode.
- * Creating/Forking a project. (only the fork will be in read only mode)
- * Adding/Removing a user/group from a project.
|