Usage scenarios

The project is written in large part to enable specific usage of Git in the small enterprise, where access to the repo server would be over intranet.

My personal preferences were:
- Must be deployable everywhere with outmost ease. Primary target deployment scenarios:
– Double-click on the script and have it run against Python’s own builtin WSGI server – no fuss whatsoever.
– Must run on IIS (Microsoft Windows Internet Information Services) over WSGI. ISAPI_WSGI tested to work. Working on NWSGI compatibility.

Principles:
- Absolute majority of “commodity” tasks (user authentication, static file serving) is delegated to the host server technology or to stand-alone WSGI components that are not Git-specific. Only Git-specific protocol handshaking and dynamic content serving is ghettoed into very shallow WSGI layer. THIS MEANS IN COMMAND-LINE MODE THERE IS NO USER MANAGEMENT.

- repo “URI” should be “dynamic” as in should not be strongly mapped from root to folder to mirror file storage structure. URI prefix (portion after FQDN and before “repo-path-starts-here” marker, can be absolutely anything, which allows deployment of the repo root URI into nested URI chain. Example http://server.com/mydynamicapp/trash/randomtrash/repo_marker/actual/path/to/repo/on/disk

- User management is still not decided upon. I am happy with “all can write / read” from start, with eventual addition of “user right management” modules. Because the storage of user rights may differ per deployment, the rights mgmt code will be abstracted away as much as possible. My first target right management storage modules are – simple in-python dict-based, and Active Directory-based (with storage of rights to repos right in the AD).

- The /actual/path/to/repo/on/disk/ part of the path should eventually become an alias to real path. This would allow internal mapping of paths like /joesmith/repo_A/ to /1234ABDC3134BC4234/ and allow group ownership of same repos, while providing pesonalized, “pretty” repo URIs to each group member.

- Need one particular feature – repo autocreation on push. This means if user with adequate permissions is pushing a repo to a URI whose actual filesystem path does not exist, the server will transparently create the repo and will take the push. It is important for our organization to have as little friction as possible to push up the code. If we can bypass the “go to the UI and create a repo by hand, pull, merge, push” that would be gold.