bzr branch reports a conflict!

Bug #33335 reported by Andrew Bennetts
2
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
Robert Collins

Bug Description

$ bzr branch -r 3179 launchpad-upstream/ lp3179
bzr: WARNING: Conflict adding file lib/canonical/launchpad/doc/validation.txt. Moved existing file to lib/canonical/launchpad/doc/validation.txt.moved.
1 conflicts encountered.
Branched 3179 revision(s).

("launchpad-upstream" is an rsynced copy of rocketfuel-built as of 2006-02-02, for Canonical people that can access it.)

Unsurprisingly, the resulting checkout reports a heap of noise from "bzr st".

Revision history for this message
Aaron Bentley (abentley) wrote : Re: [Bug 33335] bzr branch reports a conflict!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
| Public bug reported:
| https://launchpad.net/malone/bugs/33335
|
| Affects: bzr (upstream)
| Severity: Normal
| Priority: (none set)
| Status: Unconfirmed
|
| Description:
| $ bzr branch -r 3179 launchpad-upstream/ lp3179
| bzr: WARNING: Conflict adding file
lib/canonical/launchpad/doc/validation.txt. Moved existing file to
lib/canonical/launchpad/doc/validation.txt.moved.
| 1 conflicts encountered.
| Branched 3179 revision(s).
|
| ("launchpad-upstream" is an rsynced copy of rocketfuel-built as of
| 2006-02-02, for Canonical people that can access it.)

Bzr branch should be doing a build-tree, not a merge or revert, so
1. It should not produce conflicts
2. It should throw an exception if there are

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEBmfN0F+nu1YWqI0RAoygAJ9SBJpSQ+Ktkv1JTitY9w1jbFWX1wCdGomu
QPB594YE7EzUf1eP0Rx9eK8=
=9LUb
-----END PGP SIGNATURE-----

Revision history for this message
Robert Collins (lifeless) wrote :

On Thu, 2006-03-02 at 03:36 +0000, Aaron Bentley wrote:

> Bzr branch should be doing a build-tree, not a merge or revert, so
> 1. It should not produce conflicts
> 2. It should throw an exception if there are

It seems desirable that 'branch' preserve outstanding changes in a
working tree - at least one user has been confused that it was not a
full copy of the tree state.

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Revision history for this message
Aaron Bentley (abentley) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
| Public bug report changed:
| https://launchpad.net/malone/bugs/33335
|
| Comment:
| On Thu, 2006-03-02 at 03:36 +0000, Aaron Bentley wrote:
|
|
|>Bzr branch should be doing a build-tree, not a merge or revert, so
|>1. It should not produce conflicts
|>2. It should throw an exception if there are
|
|
| It seems desirable that 'branch' preserve outstanding changes in a
| working tree - at least one user has been confused that it was not a
| full copy of the tree state.

Perhaps clone should do that, but when I want that behavior, I use cp
- -r. I only use branch when I want a fresh copy. And you can't satisfy
both "branch -r" and "clone semantics" in one command. I most certainly
do not want unversioned files or the modifications of files when I
branch-- usually I branch because I've got modifications, but I want to
work on something else in parallel.

Anyhow, this is a behavioral change, so I think it's appropriate to get
consensus first before making it.

If you're including unversioned files, well none of the tree primitives
include that, so you shouldn't use any. Just do the python equivalent
of cp-r. If you're just doing source files, build-tree will do the trick.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEBnGt0F+nu1YWqI0RAqu9AJ9ae9qNi3IZAznBt2Sw9zJOrm2Q1QCePcaT
GLWnbseAUrXXCkGaIBfYw50=
=9sxD
-----END PGP SIGNATURE-----

Revision history for this message
James Blackwell (jblack) wrote :

I can't confirm this particular instance. I have seen it happen though. We need to review this prior to 0.8 and decide whether its fixable or needs to be punted.

Changed in bzr:
status: Unconfirmed → Confirmed
Changed in bzr:
assignee: nobody → lifeless
Revision history for this message
Andrew Bennetts (spiv) wrote :

Robert thinks he fixed this some time ago, and I can no longer reproduce it, so I'm going to assume he's right. Thanks!

Changed in bzr:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.