Hi Gabriel,

thanks your post and your interest in improving OpenProject on a technical level, we appriciate very much.

Our current implementation for reposititories is quite limited and although git functionality is still in the code (in lib/redmine/scm/adapters/git_adapter.rb) we don’t officially support it. Therefore, if you haven’t had a look that specific part of the source code I would suggest you do so and see whether slight modifications can solve your use case already. You’d probably also have a look at /extra/svn/reposman.rb which, despite its file location, also supports git through the —scm parameter. We would be happy to accept pull requests to fix the last pieces to make everything work smoothly. It doesn’t support fetching remote repositories, though.

In Summary, here’s what’s already there (purely for documentation puposes):

• You can enter the path to a local bare git repository (or a “.git” folder in a full clone) and then browse the repo in OpenProject. It’s implemented through calls to the git binary on your system. Initially it can be extremely slow depending on the size of the repo.
• There’s also a script called reposman.rb which checks whether repositories need to be created. Due to an implementation detail you can only create one type of repositories for the whole instance with it. It defaults to subversion but git can be used by specifying the “—scm git” flag. In it’s current state this is untested and not supported but from what i can see it should work.

Nevertheless, we aren’t satisfied with the current solution of our repository code and already have open requests on implementing mercurial again (https://www.openproject.org/work_packages/2291). We think, the best approach is to modularize this part of the code so each repository type could be implemented as a separate independent gem.This requires developing the supporting code first, most likely during extraction of an already implemented scm adapter like subversion. We cannot maintain all scm adapters that people might want to use and by having them in separate gems we could delegate that responsibility to motivated community members. We would just make sure that the repositories abstraction works well and provide a reference implementation. Ultimately, the approach would also lead to the possibility of having more than one adapter that implements a single scm (e.g. one by shelling out, the other by wrapping libgit2). This would ease the process of using more advanced adapters as they can just be switched out as needed.

Long story short, if you can help us implementing this kind of abtraction while implementing the libgit2 based approach, we would support it. This would also bring us closer to supporting mercurial again and still keeps the core clean of any modules that are’n required by the majority of users. Maybe you and Chris Larsen (https://www.openproject.org/work_packages/2291) are able to team up on this.

Please tell us what you think about the above and whether you find the topic interesting.

This became rather long, let me also present my thoughts on the other points you mentioned.

• remote repositories
  Cloning remote repositories to local is not supported at the moment. but once you have it local the above applies.

• sucker_punch
  Asynchronous processing of tasks related to repostiories is desireable. Currently async jobs are done throguh delayed_job and we would like to stick with it for the near future. As far as I can tell, sidekiq and sucker_punch use parallel threads instead of processes. As OpenProject is currently not in a thread-safe state it will be difficult to ensure there aren’t any problematic side-effects. This means, we would much more prefer asynchronous jobs written using the delayed_jobs library.

• repo updates
  Whenever you go to the repositories#show action, the database is populated with the new commits that happenend when you hit that page the last time. it’s synchronous and not triggered by any other hooks. For remote repositories, hooks would be very desireable.

• whenver
  A decent whenever file would be a great help for anyone that want’s to deploy OpenProject by him or herself.

• libgit2
  Implementing the git repository adapter with libgit2 bindings is a very good idea. We would like to see that in OpenProject.

I hope, that helps you to understand the current implementation better and makes clear where we eventually want to be regarding repositories and OpenProject Core code in general.
Let’s keep this discussion going!

Best regards,
Martin

Hi Martin,

Martin Linkhorst wrote:

Our current implementation for reposititories is quite limited and although git functionality is still in the code (in
lib/redmine/scm/adapters/git_adapter.rb) we don’t officially support it.

does “still” mean repository/source code integration will be dropped some time?

Michael

The goal is to strip the existing repository adapters in the OpenProject Core down to an abstract adapter module that is extended through plugins/gems for multiple revision control systems.
Until that abstraction is properly defined (and at least the counterparts for Subversion and Git exist in a stable version), these functionality will probably remain in the core.

You can find a relevant epic WP concerning this topic at https://www.openproject.org/work_packages/12808

Best regards,
Oliver

Are there any news on this front? I would be interested in integrating Fossil (http://www.fossil-scm.org) with OpenProject, but I lack knowledge about Rails and Redmine to write up some code. If a simpler interface with clearly defined API would exist, it would certainly be a big help.