Content
View differences
Updated by Niels Lindenthal almost 11 years ago
**As an** OP developer
**I want to** have a loosely coupled, modularized repository code base
**So that** I can easily maintain and extend SCM code.
We would like to extract the code for repositories into their own gems. Therefore, we need to refine and document an abstract repository adapter API. The current implementation isn’t too bad regarding modularity and sould be taken as a starting point.
The API should be generic enough to support local as well as remote repositories transparently as well as support repository-like backends, e.g. filesystem. On the other hand it should be easy to use and method calls should “just work”
**Goals of this refactoring:**
- Move pluggable functionality from the core into gems to make the core lighter and easier to maintain
- Ease the process of maintaining and adding new adapters to OpenProject (mercurial, gitolite, …)
- Delegate responsibility of maintaining individual adapters to the respective gem maintainers
- Allow different implementations for the same SCM to be swapped out as well as coexist (that’s more of a check whether the implementations are truly isolated)
**Things to do:**
- Define and document an API for the Repository abstraction.
- make the current adapters compatible with that API
- extract the current adapters to plugins
**for reference:**
- mercurial support: https://www.openproject.org/work\_packages/2291
- git based on libgit2: https://www.openproject.org/topics/1166
## Some thoughts
I had a look at the current repository adapters and compiled a rough set of features the API should support.
Repository Meta Information
- scm name
- version
- url/path
- credentials
…
Access Repository Contents (read-only)
- authors
- branches
- tags
- commits
- entry/blob (contents files per commit and path)
- fetch/checkout
- blame (latest information per line of file)
OpenProject Integration
- fetch commits and store them in OP’s ActiveRecord classes (Repository, Changeset, Change)
- scan commit messages for references to work packages
- map scm authors to OP’s user accounts
- list of attributes being configurable through OP’s UI
- annotation of commits/lines
- feed the activity provider
**I want to** have a loosely coupled, modularized repository code base
**So that** I can easily maintain and extend SCM code.
We would like to extract the code for repositories into their own gems. Therefore, we need to refine and document an abstract repository adapter API. The current implementation isn’t too bad regarding modularity and sould be taken as a starting point.
The API should be generic enough to support local as well as remote repositories transparently as well as support repository-like backends, e.g. filesystem. On the other hand it should be easy to use and method calls should “just work”
**Goals of this refactoring:**
- Move pluggable functionality from the core into gems to make the core lighter and easier to maintain
- Ease the process of maintaining and adding new adapters to OpenProject (mercurial, gitolite, …)
- Delegate responsibility of maintaining individual adapters to the respective gem maintainers
- Allow different implementations for the same SCM to be swapped out as well as coexist (that’s more of a check whether the implementations are truly isolated)
**Things to do:**
- Define and document an API for the Repository abstraction.
- make the current adapters compatible with that API
- extract the current adapters to plugins
**for reference:**
- mercurial support: https://www.openproject.org/work\_packages/2291
- git based on libgit2: https://www.openproject.org/topics/1166
## Some thoughts
I had a look at the current repository adapters and compiled a rough set of features the API should support.
Repository Meta Information
- scm name
- version
- url/path
- credentials
…
Access Repository Contents (read-only)
- authors
- branches
- tags
- commits
- entry/blob (contents files per commit and path)
- fetch/checkout
- blame (latest information per line of file)
OpenProject Integration
- fetch commits and store them in OP’s ActiveRecord classes (Repository, Changeset, Change)
- scan commit messages for references to work packages
- map scm authors to OP’s user accounts
- list of attributes being configurable through OP’s UI
- annotation of commits/lines
- feed the activity provider