Preliminary implementation of server-side forking (issue 137)
The fork mechanism clones the repository , access restrictions, and
other config options. The app has been updated throughout to handle
personal repositories and to properly display origin/fork links.
In order to fork a repository the user account must have the #fork role,
the origin repository must permit forking, and the user account must
have standard clone permissions to the repository.
Because forking introduces a new user role no existing user accounts can
automatically begin forking a repository. This is both a pro and a con.
Since the fork has the same access restrictions as the origin repository,
those who can access the origin may also access the fork. This is intentional
to facilitate integration-manager workflow. The fork owner does have the
power to completely change the access restrictions of his/her fork.
Draft project pages, project metadata, and RSS feeds
This is an in-progress feature to offer an interface for grouped
repositories. This may help installations with large numbers of
repositories stay organized. It also will be part of a future,
more advanced security model.
Reorganization of resources. Dropped most hard-coded webapp
configuration in favor of common web.xml file. Still contemplating
configuring git servlet from web.xml too.
Added AccessRestrictionFilter and simplified authentication.
Replaced servlet container basic authentication with a custom servlet
filter which performs the same function. The advantage to this is
that the servlet container is now divorced from the webapp.
The login service (realm) also simplified a great deal and removes its
Jetty dependencies.
Additionally, the basic authorization pop-up will be displayed as
needed based on the repository's access restriction. This was
necessary for view-restricted repositories with the RSS feature. Its
also necessary for completely open repositories as before it would
prompt for credentials.
Improved feed syndication feature.
James Moger