In another computer (same kind of linux x86_64, same version of fossil) I could pull that just fine. I'm using the same user for pulling in both computers, so that also should not be the difference.

I think that '-httptrace' does not work on 'configuration ticket pull'. How should I debug what happens?

Thank you, Lluís.

viriketo added on 2011-04-21 15:37:42 UTC:
I wanted to make clear that fossil gives no complain. It acts as if all the ticket configuration was pulled properly.

drh added on 2011-04-21 19:37:18 UTC:
The syntax is:

fossil configuration pull ticket

viriketo added on 2011-04-21 19:56:24 UTC:
Sorry, that is what I meant I wrote.

I just got a 2nd computer with the same trouble:

$ fossil configuration pull ticket
                Bytes      Cards  Artifacts     Deltas
Sent:             336         11          0          0
Received:       16284          6          0          0
Total network traffic: 378 bytes sent, 2526 bytes received

I check both the ticket part of the ui, and exporting the ticket configuration, and both are outdated. They don't have the last changes on the server: I had changed some ticket reports on the server.

Maybe updates to ticket reports do not travel through configuration pull/push?

viriketo added on 2011-04-21 20:17:43 UTC:
Ok, reading a bit the code helped.

On 'configuration pull', in xfer.c it sets configure_prepare_to_receive(0); (no replace).

So, after knowing this, I remove the ticket report and then pull, to get it updated. And it works.

Maybe the fossil help configuration should mention that 'pull' acts like 'merge', and not like 'import'.

Thank you, Lluís.

anonymous added on 2011-04-23 00:17:46 UTC:
Have not yet encountered this behavior, because, so far, we've had no need to update any of the reports, since we worked through the various changes before general deployment.

I assume this behavior is meant to preserve local changes?

I think that when local changes have not been made, pull should bring in updates to the ticket configuration, including reports.

viriketo added on 2011-04-26 05:38:01 UTC:
As for me, I can't complain on the current behaviour, other than the documentation should specify that 'pull' acts as 'merge', and not as 'import'.

The current implementation has some advantages in terms of simplicity of code. If someone wants to make it more complex, still with a clear comfortable behaviour, fine for me too.

drh added on 2011-04-27 12:17:35 UTC:
Check-in [1654456ef5aa8d38c809414a5345bd7f7e76d3c7] adds an "mtime" column to the table that holds report formats so that a "configuration sync" operation will always take the most recently edited report format from the two repositories being synced. This should fix the problem described here.

Note, however, that a irreversible schema change occurs when upgrading to the new version. And you need to upgrade all participating repositories before the fix will take effect.

Note also that when upgrading the "mtime" field is initialized to the time of the upgrade. So after upgrading two repos A and B, the first time you do a configuration sync, the one that was updated second will have the most recent mtime values on all entries and hence its report formats will always dominate over the report formats in the other repository. So be careful that you do not overwrite report formats (or other configuration information such as user passwords and capabilities) that you care about. Upgrade the definitive repository last.