Checkout existing branch to established workspace (.moved)

[Bulgrien, Kevin]

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:

http://en.wikipedia.org/wiki/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.