Committer sometimes not identified correctly

[Markus Heimhuber]

Hi,

We are using smart commits intensively with our Crucible 2.7.15 (with SVN) installation. Sometimes the committer for a single change set is not identified correctly and displayed as user crucible. Does anyone have any idea how to resolve this?

Example changeset

[crucible@myhost ~]$ svn log -r25537 file:///var/lib/crucible/svn/myproject@25537
------------------------------------------------------------------------
r25537 | myuser@mydomain.loc | 2012-11-28 14:15:07 +0100 (Wed, 28 Nov 2012) | 1 line

No duplicate positions anymore if multiple usages exist +review CR-LRS3-287
------------------------------------------------------------------------
[crucible@myhost ~]$

Contents in Crucible database:

select * from cru_revision where cru_revision = '25537'

==>

23037;1354116897713;1354108569886;"crucible";f;"FILE";f;f;t;f;f;2;"liquirisk";624;"25537";"25537";12879;f

This shows, that the committer is identified wrong as "crucible". This happens very seldom with different committers (about every 1000th commit), but is very ugly since we are missing changesets for reviewing regularily.

Any help is appreciated!

Thank you,

Markus

[Conor · Accepted solution]

Svnsync is not an atomic protocol. It works roughly by replaying the commit using the local svnsync user and then updating the commit author, etc by setting the approporiate revprops.

It is possible for Crucible to see the commit before the revprop is updated, which is what I believe is happening in your environment.

Currently Crucible does not look at the svn:sync-currently-copying revprop. I have created an enhancement issue to track this https://jira.atlassian.com/browse/FE-4386

One workaround is to off repository polling in FishEye and have the svnsync process trigger FishEye indexing manually.

[Markus Heimhuber]

Thank you for your helpful answer! Until your enhancement issue is resolved someday, we are going to implement the suggested workaround. Disabling the repository polling and calling "fisheyectl scannow" after syncing should do the job.

[Markus Heimhuber]

Yes, that is true. We are syncing the repository to our Crucible server. SVN server and Crucible server are in different datacenters and we are experiencing very poor performance if Crucible is using the main SVN server directly.

Are there any known issues with mirrored SVN repositories? I didn't expect any trouble from this side...

[Conor]

Are you using svnsync?