CommitTicketUpdater should work with svnsync

[anonymous]

Hi,

we have a special scenario here:

1. Server1: A base svn repo where we do our svn commits and updates.
2. Server2: A separate server running trac. We use svnsync to get the svn repo from Server1 to Server2. The svn "synced" repo on Server2 is used by trac.
3. we use the CommitTicketUpdater on trac/server2.

All works fine with one exceprion:

The CommitTicketUpdater always sets the name 'root' (the root users starts the svnsync in a cron job) on the ticket update. The result is that in the timeline it appears that a user root did the ticket-update instead of the real user who did the commit. (In our timeline Ticket updates is always on)

Is there a possibility to make this work??

Stephane

[Remy Blank]

That's weird. The commit updater uses the author field of the changeset as the ticket comment author. If you look at the repository on server2, do all commits appear to come from root as well?

[bdobry@…]

My guess is that the svnsync first commits the changes, causing the post-commit hook to run which runs the commit updater, and generates the ticket comment. Afterwards, svnsync does a revprop change to set the correct author, etc, triggering the post-revprop-change hook. At this point, the comment has already been added to the ticket with the svnsync user as the author and it does not try to find and change the author.

I am also interested in fixing this because I would love to use this feature, but I really don't want all of the changes to be by "svnserve" and not know who really did it. Maybe the simplest way would be to have an option of only running the commit updater after revprop-changes (obviously this would be an option so people not using svnsync could leave it as-is).

[bdobry@…]

I tried doing nothing inside of changeset_added (return right away) and I do successfully see the comments coming in with the correct username. The problem though is that there is a duplicate of that comment. I'm not sure why, but will continue investigating.

[Remy Blank]

That's a very clever explanation, and most probably correct, too. Looking at the sources of svnsync, it looks like it depends on the version of SVN, 1.5 and later seem to be able to commit revprops together with normal data. What version of SVN are you using?

But in this case, the fix is simple: don't call trac-admin $ENV changeset added from the post-commit hook, but from the post-revprop-change hook, which is called after every commit anyway. As you won't be committing with anything else than svnsync, this should work fine.

[bdobry@…]

I'm using svnsync version 1.6.6, and it definitely seems to commit the change, then do the revprops. I like the very simple solution of only calling it in post-revprop-change. Once again, I get the comments with the proper author, but there are duplicates.

[bdobry@…]

Maybe of interest is the fact that the two comments are 2 seconds apart in time. Does this cause the "_is_duplicate" method to return false?

[Remy Blank]

Replying to bdobry@…:

Maybe of interest is the fact that the two comments are 2 seconds apart in time.

Ah, the problem is that the post-revprop-change hook is called once for each revprop (author, time, …). Can you please add a line to your post-revprop-change hook that prints the revision ($2) and the name of the property that is set ($4)? Also add a print in the post-commit hook that prints the revision ($2). Then we will see the pattern that svnsync uses.

[Matt Behrens <mbehrens@…>]

Replying to rblank:

Ah, the problem is that the post-revprop-change hook is called once for each revprop (author, time, …). Can you please add a line to your post-revprop-change hook that prints the revision ($2) and the name of the property that is set ($4)? Also add a print in the post-commit hook that prints the revision ($2). Then we will see the pattern that svnsync uses.

Since you didn't get a reply, I did my own investigation:

The post-revprop-change hook actually gets called a lot by svnsync:

Nov 10 15:53:35 cb-builder post-revprop-change[22109]: REPOS=/home/trac/var/lib/svn/sandbox REV=0 USER=trac PROPNAME=svn:sync-lock ACTION=D
Nov 10 15:53:38 cb-builder post-revprop-change[22114]: REPOS=/home/trac/var/lib/svn/sandbox REV=0 USER=trac PROPNAME=svn:sync-lock ACTION=A
Nov 10 15:53:38 cb-builder post-revprop-change[22117]: REPOS=/home/trac/var/lib/svn/sandbox REV=0 USER=trac PROPNAME=svn:sync-currently-copying ACTION=A
Nov 10 15:53:40 cb-builder post-revprop-change[22124]: REPOS=/home/trac/var/lib/svn/sandbox REV=3 USER=trac PROPNAME=svn:author ACTION=M
Nov 10 15:53:40 cb-builder post-revprop-change[22127]: REPOS=/home/trac/var/lib/svn/sandbox REV=3 USER=trac PROPNAME=svn:date ACTION=M
Nov 10 15:53:41 cb-builder post-revprop-change[22130]: REPOS=/home/trac/var/lib/svn/sandbox REV=0 USER=trac PROPNAME=svn:sync-last-merged-rev ACTION=M
Nov 10 15:53:41 cb-builder post-revprop-change[22133]: REPOS=/home/trac/var/lib/svn/sandbox REV=0 USER=trac PROPNAME=svn:sync-currently-copying ACTION=D
Nov 10 15:53:41 cb-builder post-revprop-change[22136]: REPOS=/home/trac/var/lib/svn/sandbox REV=0 USER=trac PROPNAME=svn:sync-lock ACTION=D

So I put this code into my post-revprop-change, which seemed appropriate and updates the timeline as I'd expect:

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

HOME=/home/trac
PROJECT=$HOME/var/lib/trac/sandbox

if [ "$PROPNAME" = "svn:author" ]
then
        $HOME/bin/trac-admin $PROJECT changeset added "sandbox" $REV
fi

[Christian Boos]

So IIUC, with the above post-revprop-change, things works as expected…