Content
View differences
Updated by Oliver Günther almost 11 years ago
With my previous knowledge of Git(olite) and Smart HTTP, I naturally introduced a project parent hierarchy in the storage of managed repositories.
For example, two projects with repositories:
- Parent project ‘foo’ with Git repository
- Child project ‘bar’ with SVN repository
Results in the directory structure:
- <Managed Root>
- foo.git
- foo
- bar.svn
With the Git smart HTTP approach taken in https://github.com/opf/openproject/pull/3289, this approach still works, as Git simply uses the URL path to locate a repository and also allows to override that path using ENV variables.
As it turns out, there are two problems:
1. As it turns out, `mod_dav_svn` does not allow subdirectories inside its `SVNParentPath`****, which seems counterintuitive but may be related to the path-based access control available in Subversion.
2. The way the PR solves Git smart HTTP is by using a **separate** directory for Git.
I thus suggest we refactor the output of managed repositories to be the following:
- git
- foo.git (`.bar` commonly denotes a bare repository and is supported by the Apache handler)
- subversion
- bar
As project identifier have to be unique at any level, this will not have any clashes.
It will also allow us to avoid the moving of repositories (as happening at the moment at Gitolite) when parent projects were renamed.
It MAY lead to a large number of directories inside these top-level vendor directories (however directory limit for some FS seem to be around 2^15).
This refactoring comes at no essential effort.
For example, two projects with repositories:
- Parent project ‘foo’ with Git repository
- Child project ‘bar’ with SVN repository
Results in the directory structure:
- <Managed Root>
- foo.git
- foo
- bar.svn
With the Git smart HTTP approach taken in https://github.com/opf/openproject/pull/3289, this approach still works, as Git simply uses the URL path to locate a repository and also allows to override that path using ENV variables.
As it turns out, there are two problems:
1. As it turns out, `mod_dav_svn` does not allow subdirectories inside its `SVNParentPath`****, which seems counterintuitive but may be related to the path-based access control available in Subversion.
2. The way the PR solves Git smart HTTP is by using a **separate** directory for Git.
I thus suggest we refactor the output of managed repositories to be the following:
- git
- foo.git (`.bar` commonly denotes a bare repository and is supported by the Apache handler)
- subversion
- bar
As project identifier have to be unique at any level, this will not have any clashes.
It will also allow us to avoid the moving of repositories (as happening at the moment at Gitolite) when parent projects were renamed.
It MAY lead to a large number of directories inside these top-level vendor directories (however directory limit for some FS seem to be around 2^15).
This refactoring comes at no essential effort.