QB3: Promotions fail second time #1144

We have used the promotion model to pass one build from one group to another ever since QB1.X. With QB3, I think I am doing something wrong because the second time I try to promote either the same build to the same location, or a different build, I get an error in this form for my promotion destination:

Failed to run command: /opt/CollabNet_Subversion/bin/svn log https://evc.io.comcast.net/gw-scmtools/trunk/ --non-interactive --username gw-builder --password ****** -v --xml -r 5642:5637 , returned code: 1

In my original configuration, We perform two checkouts. The first is for the code that we build, and the second is for a set of helper-scripts that we run post-build to do extra activities.

In the error message above, what I see is that the revision number of the first repository is being used to determine the revision history of the helper module. I think this has to do with an incompletely specified "Snapshot Taking" setting currently at "Take snapshots for all referenced repositories." I think that if I configure this section correctly, I can get the promotion to always work.

In short, I think that I would like to disable the section, but I am not sure how to do this. I searched a bit for some online help and examples, but I have not come to any conclusion yet. We are only promoting artifacts, and not source, so the connection to source is lost once we make the promotion.

What can I do?

During promotion, QuickBuild tries to calculate changes since previous build in the destination configuration in regardless of source being checked out or not, as explained in the last section of below link:
http://wiki.pmease.com/display/qb30/Promote+Build

QuickBuild achieve this by comparing repository revisions stored in the build being promoted for the first time and for the second time, using repository definitions found in destination configuration based on repository name.

If revision of the first repository is used for helper module to calculate changes, it means that the same repository name is used for the first repository defined in source configuration and the helper repository defined in destination configuration. Once you obey the rule that the same repository uses the same name in both configurations, and different repository never uses the same name, the problem will disappear.