Checkout existing branch to established workspace (.moved)

Mark Grandi markgrandi at
Fri Mar 23 21:57:33 UTC 2012

uhhh yeah, i was recovering from a mac windowserver crash and i forgot who
the conversation was with, since its obviously vila when you look at it.

On Fri, Mar 23, 2012 at 2:41 PM, Jelmer Vernooij <jelmer at> wrote:

>  Hi Mark,
> Are you sure you mean me, rather than somebody else? I don't seem to be in
> that IRC conversation and I don't remember having it.
> Cheers,
> Jelmer
> Am 23/03/12 21:13, schrieb Mark Grandi:
> (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
>> VCS
>> 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