Hi Ethan On Monday, December 2, 2013 5:17:50 PM UTC+1, Ethan Jucovy wrote:
> On Mon, Dec 2, 2013 at 10:32 AM, Michael Schwarz > <[email protected]<javascript:> > > wrote: > >> When I create a new commit and notify Trac manually, I see the following: >> >> $ venv/bin/trac-admin $ENV changeset added '(default)' r24 >> > > I just set up a test environment, and I'm seeing the same behavior as you > with this command. It looks like the issue here has to do with the "r24" > spelling: the SVN backend bails out with an error before Trac even gets to > notify any plugins about the changeset_added event. > > If I run the same command without the "r" prefix, it works fine: > > $ venv/bin/trac-admin $ENV changeset added '(default)' 24 > > Can you try that out and see if it works for you too? I suspect that it > will. > I could reproduce your findings, it does work correctly when dropping the "r". (You may also want to switch your MultiRepoSearchPlugin installation to a > direct-from-git install[1] for now -- I just pushed a change to make better > use of debug logging.) > I didn't have time yet, I will try to get to that soon. > When you were building that trac-admin shell command, where did you get > the "r24" (versus just "24") from? What does your SVN post-commit hook > look like? > I ran the "changeset added" command above manually from the command line while I was debugging a related problem (below). I used the r24 syntax just because the Trac user interface also uses that notation. I would not have been surprised if it had been rejected but because the changesets were added to the source browser and I could not identify an error message in the logs, I assumed that's the correct syntax and didn't think about it any more. > Depending on whether "r24" is intended to be a supported syntax here, this > looks like it's either a bug in your post-commit hook, or in Trac core's > `normalize_rev` function(s), which currently raise a NoSuchChangeset > exception when something like "r24" is passed in. > I'd be fine with only one syntax being accepted and the other one being rejected with a clear error message. When I run the command with the "r24" syntax, I'm not seeing any indication of an error, in the logs or on the command line, which is IMHO suboptimal. Maybe you can also help with the problem I'm actually trying to solve. In our setup, the SVN repositories and the Trac instance are not hosted on the same machine. The Trac instance can access the repositories via an NSF mount, which works fine. But a post-commit hook would need to use e.g. ssh to run the trac-admin command on the other server. So I thought it would instead be simpler to have a script on the server running the Trac instance that looks for any change in any of the repositories once a minute and just call "trac-admin $ENV repository sync '*'" regardless of which repository has changed. The gist of that script is: LAST_STATE=$(< "$STATE_FILE") CURRENT_STATE=$(grep -F '' /mnt/svn/*/db/current | sha1sum) if [ "$CURRENT_STATE" != "$LAST_STATE" ]; then echo "$CURRENT_STATE" > "$STATE_FILE" trac-admin "$ENV" repository sync '*' fi That has been working very well for half a year and I assumed that the "sync" command will trigger all the same events inside of Trac as a "chnagesat added" would, except maybe less efficient. But a few weeks ago I noticed that the MultiRepoSearchPlugin was not finding new stuff in the repositories and so I investigated. What is your view on this? Do you think It makes sense to expect my approach of notifying Trac of changes in the repositories? Otherwise I would just rewrite my script to instead issue the correct "changeset added" commands. Regards Michael -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/groups/opt_out.
