'trac-admin changeset added' adds changeset as invalid user

[cv.mail@…]

I'm trying to explicitly notify trac about new changeset in mirrored repository (which is updated by svnsync). Instead of getting username of author from SVN (from specified REV), it uses current UID as author name.

Behaviour without explicit notification of trac is normal (uses author from SVN, not apache's one).

[Remy Blank]

Yes, that's a known issue. When mirroring, svnsync first commits with user "svnsync", then modifies the changeset metadata to match what the changeset says. This runs the changeset hook twice, once with "changeset added" and once with "changeset modified". The ticket update is done in the former, when the user isn't available.

I haven't found a solution for that yet, so all suggestions are welcome.

[cv.mail@…]

In this case this isn't problem of trac.

As for instructions of using svnsync, it should be added to manual that admin have to add post-revprop-change hook with lines like following:

REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"
read PROPVAL

if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:author" -a "$PROPVAL" = "svnsync" ]; then
  trac-admin (URL) changeset added "(default)" $REV
fi

Also notice, that there is ChangesetNotifier plug-in, which executes on changeset added, not changeset modified, that's why "changeset added" was actually added to revprop-change hook (changing author with "changeset modified" is too late because e-mail has already sent).

[Remy Blank]

That's a valid workaround as you don't ever change revprops "by hand". Ideally I would prefer finding a correct solution, especially since svnsync is what we suggest to people who want to access a remote SVN repository with Trac.

[cv.mail@…]

It's almost ideal, since you will hardly change author to "svnsync" user and back, also change of author could be prohibited by hook on original repository.

[Remy Blank]

Oh, I didn't notice that you checked the property value. But isn't the property change from svnsync instead of to?

[anonymous]

No, it's from: # [STDIN] PROPVAL ** the old property value is passed via STDIN.

[Christian Boos]

No need to delay 0.12.4 for this one.

[Ryan J Ollos]

Moved ticket assigned to next-stable-1.0.x since maintenance of 1.0.x is coming to a close. Please move the ticket back if it's critical to fix on 1.0.x.

[Ryan J Ollos]

Milestone renamed