James Sharpe wrote:

2008/5/6 Rene Rivera <grafikrobot@gmail.com>:

...

Having an svnmerge command like in this case <http://svn.boost.org/trac/boost/changeset/45029> spew commentary all over existing trac items like this one <http://svn.boost.org/trac/boost/ticket/1889>, just seems like a really bad thing.

Agreed. I didn't know that was happening.

...

Is this yet another reason not to use svnmerge? Or is it operator (not to pick on Eric) error that can be averted in the future? Or could it be the trac comment plugin causing this, and svnmerge is blameless?

Recommended usage of svnmerge.py is to commit the merged changes using `svn commit -F svnmerge-commit-message.txt`, where svnmerge-commit-message.txt is a text file containing all the commit messages for the merged changes. The file is generated by svnmerge.py. For now, I can simply commit merged changes using `-m "blah"` instead to avoid the trac spew.

I'd say that its the trac plugin. Its picking up the fact that the bugs were closed on the branch and when it sees the comment again then it tries to close the bug again. Could the trac plugin be modified to ignore comments when the string 'svnmerge' is in the log message?

If the trac plugin didn't try to close bugs that were already closed, I think the problem would go away, right?

Interesting it didn't spam http://svn.boost.org/trac/boost/changeset/45019though so trac may be doing something more complex..

Of course this can be worked around by users if it becomes a problem by removing the bug numbers from the log messages, although I'd admit its not a convenient fix and one that'd be easy to forget given the workflow for svnmerge.py

-- Eric Niebler Boost Consulting www.boost-consulting.com

Eric Niebler wrote:

Replying to self ...

Eric Niebler wrote:

...

If the trac plugin didn't try to close bugs that were already closed, I think the problem would go away, right?

Or rather, I think the track plugin should ignore changes made to a branch.

Well since svn doesn't make a distinction between branches and non-branches that's not really possible. And besides, I can see it being useful to work on bugs in a branch, like say a feature branch. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On May 11, 2008, at 8:15 PM, Eric Niebler wrote:

I don't really know how it works, but that seems unlikely to me. It's probably implemented as a trigger, which could check the commit url and take action depending on whether it contains "/branches/" or not.

That's easy to do, if we agree that it's the right thing to do. What do you think, Rene?

Rene Rivera wrote:

...

And besides, I can see it being useful to work on bugs in a branch, like say a feature branch.

I think it's reasonable to restrict the automatic closing of trac tickets to commits on trunk.

The only issue here is that we don't release code from the trunk; there's an extra merge-to-release step that has to occur before the bug is really "fixed" from the perspective of our users. Should the bug be considered "fixed" before the change is merged to the release branch? - Doug