Bug #26331 autopush --target_first tries to pull on a new (empty) tree
Submitted: 13 Feb 2007 16:16 Modified: 16 Mar 2009 12:04
Reporter: Ingo Strüwing Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Tests Severity:S3 (Non-critical)
Version:autopush OS:Any
Assigned to: Jani Tolonen CPU Architecture:Any

[13 Feb 2007 16:16] Ingo Strüwing
Description:
The new option --target_first tries to pull the GCA changeset from the target repository. This works only if the repository has been used before.

Otherwise a clone would be necessary.

I got the following log:
"
Doing bk pull from launch dir to build dir
Started at Tue Feb 13 17:00:01 2007
Pulling from target host first using changeset svoj@june.mysql.com|ChangeSet|20070205113120|20096
Running: bk pull -s  -r'svoj@june.mysql.com|ChangeSet|20070205113120|20096' istruewing@bk-internal.mysql.com:/home/bk/mysql-5.1-engines
sane: no BitKeeper/etc/config file.
"

I guess, pulling would also fail if the lauch tree is behind the last push. The last push will pull the repository to the then current changeset. If one then tries to use --target_first for a tree cloned before that push, it won't reset the repository to the former GCA changeset.

How to repeat:
~/internals/dev/autopush.pl --build_dir=autopush --email_addr=ingo@mysql.com --use_bkd --bk_user=xxx --target_first --target_dir=/home/bk/mysql-5.1-engines

Suggested fix:
Use 'clone' instead of 'pull' with the --target_first option. You also need to remove the build tree first.
[16 Mar 2009 12:04] Daniel Fischer
We don't use autopush with bzr.