Checkout existing branch to established workspace (.moved)

[Jelmer Vernooij]

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
> (http://bpaste.net/show/25779/) 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 gdsatcom.com <mailto:Kevin.Bulgrien at gdsatcom.com>> 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:
>
>     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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120323/73c73330/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120323/73c73330/attachment.pgp>