Andreas Schuh wrote:

Any ideas on how this could be achieved? A solution on the database level which is actually rather independent of ChiliProject/Redmine would be desired.

That's complicated at best because you're then dependent on the exact schema of the DB, the data in the DB is tightly coupled together, and I guess even things like auto increment columns will be hard to get done in an async manner (instance A claims "the next" ID, instance B claims "the next" ID too before they are synced, what now?). Long story short, I don't know of any solution to have ChiliProject or Redmine instances periodically synchronized.

Shameless plug: we (finn) might be able to help, feel free to contact us for more information.

I am currently working on a similar problem for our faculty.

What I have in mind is a remote tracking of bugs, similar to the feature in Launchpad or Bugzilla. You just add a link to the remote bug and the bugtracker fetches more details.
This could be implemented as a plugin, possibly with some bot periodically fetching and updating bugs statuses using REST API.

Yes, I see now that the solution must be at the application level (see also reply by Gert in the Redmine forum).

Querying changes from the public database A to add them also to the private database B, as well as to synchronize existing rows which correspond to the same record. Here of course one needs to establish such correspondence between the database rows with differing primary key (e.g., issue ID). Therefore, I was thinking about adding a column to the tables of interest in the private database B, which would indicate the corresponding rows in the tables in database A. Then, either a plugin or a process which makes use of the REST API would be responsible to keep corresponding rows in sync, respectively, to add new rows in database A also to database B. Basically, this sounds doable, but I fear that as usual the crux is in the detail and requires more efforts than we can afford for this matter. One problem to deal with would probably be conflicting updates in both databases, even though I do not expect too frequent updates on the public end, i.e., database A. So I was just hoping there would be already something out there that would reduce our efforts and, not to forget, reduce the risk of leading towards a dead end...

Therefore, I would in first place focus on what we actually need to have synchronized. In first place, we are interested in the issues view related tables. So it would be a start to have only these "synchronized". Again, I would not require that the issue IDs on both ends are identical for the very same issue, only that from database B I have a reference to the corresponding issue in database A.

That the schema of both databases would be tightly coupled is not an issue here as the idea is to run the same version of ChiliProject/Redmine at both ends with the same database schema, but simply differing database content.

Andreas Schuh wrote:

[…] Here of course one needs to establish such correspondence between the database rows with differing primary key (e.g., issue ID). Therefore, I was thinking about adding a column to the tables of interest in the private database B, which would indicate the corresponding rows in the tables in database A.

You can keep this on application level too, ChiliProject/Redmine already provides custom fields functionality (such as Remote issue URL used by ChiliProject's bugtracker) – this information is also exposed through REST API.

The risk of conflicting updates depends on how much data you want to synchronize. Syncing issue's status (or other fields) is easy, you just pick the most recent issue and update its status on the other instance of CP. REST API also provides details on which fields were changed, see e.g. https://www.chiliproject.org/issues/826.xml?include=journals
Changes done through API are also logged and users are notified, which is an advantage of a highlevel approach.
If you also want to sync comments, the plugin/bot would probably need to keep information on which comments to which issues were already added – but synchronization is still quite easy given you just add stuff.

The most promising solution thus far which indeed is already implemented seems to be rubyrep as pointed out by Holger.

Task Adapter (http://www.taskadapter.com) can transfer tasks between Redmine and Chiliproject instances. If you need more control over what's transferred, you have to create a custom transformer using https://github.com/taskadapter/redmine-java-api