| | |
|---|
| | | ## Setting up Tickets |
|---|
| | | |
|---|
| | | *PREVIEW 1.4.0* |
|---|
| | | *SINCE 1.4.0* |
|---|
| | | |
|---|
| | | By default, Gitblit is not configured for Tickets. There are several reasons for this, but the most important one is that you must choose the persistence backend that works best for you. |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | tickets.service = com.gitblit.tickets.BranchTicketService |
|---|
| | | |
|---|
| | | Your ticket journals are persisted to `id/{shard}/{id}/journal.json`. These journals are stored on an orphan branch, `refs/gitblit/tickets`, within your repository. This allows you to easily clone your entire ticket history to client working copies or to mirrors. |
|---|
| | | Your ticket journals are persisted to `id/{shard}/{id}/journal.json`. These journals are stored on an orphan branch, `refs/meta/gitblit/tickets`, within your repository. This allows you to easily clone your entire ticket history to client working copies or to mirrors. |
|---|
| | | |
|---|
| | | #### Redis Ticket Service |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | Your ticket journals are persisted to a Redis data store. *Make sure you configure your Redis instance for durability!!* This particular service is highly-scalable and very fast. Plus you can use all of the power of Redis replication, should you want. |
|---|
| | | |
|---|
| | | The main drawback to this service is that Redis is primarily a Unix tool and works best on a Unix server. While there is a Windows port, sort-of maintained by Microsoft, it is not actively updated. |
|---|
| | | The main drawback to this service is that Redis is primarily a Unix tool and works best on a Unix server. Microsoft is engaged with the Redis community and they do maintain a semi-active port of Redis for Windows servers. |
|---|
| | | |
|---|
| | | tickets.redis.url = redis://(:{password}@){hostname}:{port}(/{databaseId}) |
|---|
| | | |
|---|
