gitolite/doc/g2incompat.mkd

104 lines
4.1 KiB
Markdown
Raw Normal View History

# #g2incompat incompatibility with g2
This page expands on some incompatibilities that were only briefly mentioned
in the [migration][g2migr] page.
2012-03-16 02:54:47 +01:00
## #g2i-name NAME rules
2012-03-16 02:54:47 +01:00
1. NAME/ rules must be changed to VREF/NAME/
2012-03-16 02:54:47 +01:00
2. Fallthru on all VREFs is "success" now, so any NAME/ rules you have
**MUST** change the ruleset in some way to maintain the same restrictions.
The simplest is to add the following line to the end of each repo's rule
list:
- VREF/NAME/ = @all
2012-03-16 02:54:47 +01:00
## #g2i-subconf subconf command in admin repo
2012-03-16 02:54:47 +01:00
(This is also affected by the previous issue, 'NAME rules'; please read that
as well).
2012-03-16 02:54:47 +01:00
If you're using delegation in your admin conf setup, please add the following
lines to the end of the gitolite-admin rules in your conf/gitolite.conf file:
repo gitolite-admin
- VREF/NAME/ = @all
2012-03-16 02:54:47 +01:00
subconf "fragments/*.conf"
The first part compensates for fallthru now being a success when processing
[VREF][vref] rules (NAME rules are just one specific VREF). Although,
**ideally**, you should change your ruleset so that you no longer require that
line. As the [vref documentation][vref] says:
> **Virtual refs are best used as additional "deny" rules**, performing
> extra checks that core gitolite cannot.
The second part explicitly says when and where to include the subconf files.
(Before subconf was invented, this used to happen implicitly at the end of the
main conf file, and was hardcoded to that specific glob.)
## #g2i-gl-time gl-time for performance measurement
If you've been using gl-time for performance measurement, there's a much
better system available now.
gl-time used to only log elapsed time. The new 'CpuTime' trigger module
shipped with gitolite, if enabled in the rc file, can also report CPU times
using perl's 'times()' function. See comments within that file and in the
default rc file that contain the word "cpu", for more details.
Further, you can copy that module with a different name, add your own
functionality, and invoke *that* from the rc file instead.
## #g2i-mirroring changes in mirroring setup
There are several changes with regard to mirroring:
* there is no 'post-receive' hook to be installed. Mirroring is handled by
g3's [triggers][] mechanism. Gitolite triggers are enabled by adding (or
uncommenting, in this case) appropriate lines in the rc file.
* the `GL_HOSTNAME` variable is now `HOSTNAME`. (Note that the rc file
syntax itself has changed quite a bit; to be accurate, HOSTNAME is not a
variable but a hash key with an associated value).
* the `GL_GITCONFIG_KEYS` variable is now `GIT_CONFIG_KEYS`, **but** you no
longer need to set it to anything for mirroring to work.
* the `gl-tool` program does not exist anymore. Adding keys for peer
servers is done just like adding user keys, except that the pubkey file
name must start with `server-`. For example, to add a peer host called
frodo, you will acquire its pubkey and add it as `server-frodo.pub`.
* the config variables are quite different now. The main ones now look like
this:
option mirror.master = sam
option mirror.slaves = frodo gollum
The redirectOK looks like this:
option mirror.redirectOK = frodo
The special value "true" to say that all slaves are trusted is now "all":
option mirror.redirectOK = all
* there are no more mirroring "keys", (lists of servers named in config keys
like 'gitolite.mirror.nightly', etc). You can certainly add lines like
option mirror.nightly = merry pippin
but they will not be processed by gitolite. Your cron jobs should use
`gitolite git-config` to query this variable, grab the list of repos, and
run `gitolite mirror` on each of them.
* the external command to resync mirrors is 'mirror', run just like any
other [command][commands]. In particular, you can run `gitolite mirror
-h` to get help. It cannot be run from a slave to ask a master to push
(unlike in the old system) but what's more convenient is that any user who
has any access to the master can run it remotely (if you allow it) to
invoke a push.