From ea936aa63d7a756ca7d0284f76b830656d1e8918 Mon Sep 17 00:00:00 2001 From: James Moger Date: Tue, 27 Sep 2011 09:49:57 -0400 Subject: Documentation. --- docs/02_federation.mkd | 6 +++++- docs/fed_aggregation.png | Bin 0 -> 21532 bytes docs/fed_mirror.png | Bin 0 -> 6897 bytes docs/federation.odg | Bin 0 -> 12385 bytes 4 files changed, 5 insertions(+), 1 deletion(-) create mode 100644 docs/fed_aggregation.png create mode 100644 docs/fed_mirror.png create mode 100644 docs/federation.odg (limited to 'docs') diff --git a/docs/02_federation.mkd b/docs/02_federation.mkd index e004a27a..f77d7034 100644 --- a/docs/02_federation.mkd +++ b/docs/02_federation.mkd @@ -2,13 +2,15 @@ *SINCE 0.6.0* -A Gitblit federation is a mechanism to clone repositories and keep them in sync from one Gitblit instance to another. Federation can be used for automated backup of your repositories or may be used to initially clone groups of repositories to developer workstations. If you are/were a Subversion user you might think of this as [svn-sync](http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html), but better. +A Gitblit federation is a mechanism to clone repositories and keep them in sync from one Gitblit instance to another. Federation can be used to maintain a mirror of your Gitblit instance, to aggregate repositories from developer workstations, or to initially clone groups of repositories to developer workstations. If you are/were a Subversion user you might think of this as [svn-sync](http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html), but better. If your Gitblit instance allows federation and it is properly registered with another Gitblit instance, each of the *non-excluded* repositories of your Gitblit instance can be mirrored, in their entirety, to the pulling Gitblit instance. You may optionally allow pulling of user accounts and backup of server settings. The federation feature should be considered a security backdoor and enabled or disabled as appropriate for your installation.
Please review all the documentation to understand how it works and its limitations. +![block diagram](fed_aggregation.png "Gitblit Federation Aggregation") + ### Origin Gitblit Instance Requirements - *git.enableGitServlet* must be true, all Git clone and pull requests are handled through Gitblit's JGit servlet @@ -236,6 +238,8 @@ These examples would be entered into the `gitblit.properties` file of the pullin #### (Nearly) Perfect Mirror Example +![block diagram](fed_mirror.png "Gitblit Mirror") + This assumes that the *token* is the *ALL* token from the origin gitblit instance. The repositories, example1_users.properties, and example1_gitblit.properties will be put in *git.repositoriesFolder* and the origin user accounts will be merged into the local user accounts, including passwords and all roles. The Gitblit instance will also send a status acknowledgment to the origin Gitblit instance at the end of the pull operation. The status report will include the state of each repository pull (EXCLUDED, SKIPPED, NOCHANGE, PULLED, MIRRORED). This way the origin Gitblit instance can monitor the health of its mirrors. diff --git a/docs/fed_aggregation.png b/docs/fed_aggregation.png new file mode 100644 index 00000000..556d1e47 Binary files /dev/null and b/docs/fed_aggregation.png differ diff --git a/docs/fed_mirror.png b/docs/fed_mirror.png new file mode 100644 index 00000000..3ad238e6 Binary files /dev/null and b/docs/fed_mirror.png differ diff --git a/docs/federation.odg b/docs/federation.odg new file mode 100644 index 00000000..e2c3ba8a Binary files /dev/null and b/docs/federation.odg differ -- cgit v1.2.3