Modify ↓
Opened 16 years ago
Closed 16 years ago
#8263 closed enhancement (duplicate)
Using Trac in a cross site environment
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | none |
Severity: | normal | Keywords: | distributed, cross site |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Currently I'm using Trac to track tickets in a single location. However we're soon going to have some more developers at a different location (that is only connected via e-mail). We want everyone to be sharing the same ticket tracking system (and also version tracking system).
So would it be possible to make Trac function in this manner? Be synchronize two different instances of Trac while two sets of developers both use them?
Attachments (0)
Note:
See TracTickets
for help on using tickets.
This has already been discussed before (DistributedTrac) and it's potentially a long term goal, but currently it's not really possible to do this.
In your specific case however, you could maybe come up with workarounds.
For example, you could select two different ticket ranges for each Trac instance. Let's say your location A uses tickets starting from 1 (the "normal" setup) and the location B will use tickets starting from 10000 (or even 100000 if you plan to have a lot of tickets). You can easily achieve this by doing some manipulations at the database level, either creating fake tickets entries then deleting them, or by using ALTER SEQUENCE if you're using PostgreSQL. With that setup you could relatively easily write a script to do batch transfers of tickets and ticket attachments between the two sites, provided you set some strict policy about modifications. Each site only modifies tickets in its range - you could of course still see and "talk about" the resources coming from the other site (i.e. create TracLinks referring tickets, attachments, …).
A truly distributed Trac should of course allow to share modifications on the same resources.
Duplicate of #1465.