Checkout existing branch to established workspace (.moved)

Mark Grandi markgrandi at
Fri Mar 23 20:13:58 UTC 2012

(sorry, resent. I suck at mailing lists)

Me and Jelmer had a conversation about this on IRC ( and I brought up that it would be nice to
have it so if you checkout/branch into a directory that has conflicts (aka
it tries to branch a file named foo.txt but foo.txt already exists), it
should abort the branch/checkout and tell the user, and then make them
choose to either move the conflicting files to .moved (current behavior),
replace the conflicting files, or merge them (and have them conflicting
like Kevin was wanting.

However, as jelmer pointed out having the 'merged' behavior would be hard
to due to some outstanding problems on how file-ids are tracked, but i feel
having bzr require an option to move the conflicting files to .moved would
be easy enough to implement (and just have it abort if there are
conflicting files by default), and would prevent headaches like this in the
future, until the ideal fix is figured out

On Fri, Mar 23, 2012 at 7:06 AM, Bulgrien, Kevin <
Kevin.Bulgrien at> wrote:

> I have a few cases where I have a reference shared repository/branch stored
> somewhere.  There are other locations that I want to compare to that
> reference
> branch that should have the capability of being used to update the branch
> as
> needed.
> Scenarios might be along the lines of using bzr to help a user standardize
> a
> home directory across multiple systems - including when bringing new
> systems
> up, controlling system configuration (along the lines of etckeeper), or
> converting sandboxes of other VCS over to bzr after converting the other
> repository to a bzr repository/branch.  One might also think of having a
> workspace based on a tarball, and subsequently deciding that the workspace
> should be made a checkout of a project branch.
> The idea is that some shared repository/branch is checked out into an
> existing
> workspace that is well established and working per the owner's wishes, and,
> to make a point, has over a hundred files that have minor variations to the
> branch.
> Now a the point the owner decided to checkout a project branch so that the
> branch is useful for merging stuff from the branch or committing to it, the
> owner does `bzr co someplace .`.  All of a sudden over a hundred of these
> occur:
> Conflict adding file blah.  Moved existing file to blah.moved.
> Owner screams in anguish.  The workspace is now broken.  He thinks software
> should operate by the principle of least astonishment:
> In the owner's experience, another VCS doesn't choose to do things for him
> unless he asks it to.  He realizes that by doing `bzr co` the way he did,
> that
> in a sense he asked it to to all that moving (without realizing it) BUT
> what
> he didn't ask it to do was BREAK his workspace.  That other VCS would have
> complained about conflicts and needing to move the existing stuff out of
> the
> way (or something) every time he asked for status, tried to update, etc,
> but,
> it would NOT have decided it needed to automatically move conflicts.  On
> the
> otherhand, this other VCS would have moved and renamed old files if the
> owner
> had specifically included a command-line option that explicitly requested
> something that might be dangerous.
> In short, the assumption of `bzr co` that it should rename files by
> default is
> not friendly.
> Realizing that this owner is coming to bzr late in the game, perhaps the
> community does not agree, however, there is no option even to disable
> this, in
> some scenarios, behavior.  I have searched around and found a number of
> other
> bzr users who felt the same way I do, and some on #bzr also agreed that my
> view was not altogether unreasonable.
> Is there some way that bzr can be modified to help a group of bzr users (of
> an unknown size) with the .moved issue?  Is .moved seen as "a good thing"
> so
> often that the default cannot be changed?  If not, what about prompting the
> user and telling him what is about to happen?  Or, what about having some
> kind of configuration (maybe in the repository), that suppresses the .moved
> behavior?
> Perhaps new adopters of bzr are most impacted, but, even knowing about
> .moved,
> I am not sure how to checkout a branch into a pre-existing workspace
> without
> the checkout breaking it by renaming lots of files.  I am also in the
> position
> of considering transitioning my workplace over from another VCS to bzr, and
> see this as one of the pain factors associated with advocating that change.
> Respectfully,
> Kevin Bulgrien
> This message and/or attachments may include information subject to GD
> Corporate Policy 07-105 and is intended to be accessed only by authorized
> personnel of General Dynamics and approved service providers.  Use, storage
> and transmission are governed by General Dynamics and its policies.
> Contractual restrictions apply to third parties.  Recipients should refer
> to the policies or contract to determine proper handling.  Unauthorized
> review, use, disclosure or distribution is prohibited.  If you are not an
> intended recipient, please contact the sender and destroy all copies of the
> original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bazaar mailing list