Checkout existing branch to established workspace (.moved)
aaron at aaronbentley.com
Fri Mar 23 20:52:29 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 12-03-23 10:06 AM, Bulgrien, Kevin wrote:
> 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.
So there are a lot of things that would be astonishing. It would be
astonishing if bzr co behaved differently from merge, pull, and other
commands that interact with a working tree.
> 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.
I don't understand why this breaks the workspace, or at least, I don't
understand why it's more likely to break the workspace than the
If bzr co sees that the on-disk version of a file is the same as the
branch version, it will not move it out of the way. It only moves
files when the versions differ.
So if we know that the versions differ, what is more likely to break
the workspace: using the versions from the branch, or mixing the
branch versions with the on-disk versions?
I believe that in most cases, using the versions from the branch that
were all committed together is more likely to produce a set of files
that work with each other. I believe that in most cases, using a mix
of on-disk versions and branch version is more likely to break the
workspace, because the on-disk versions won't match the branch
> 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.
We do not generally consider moving files to be dangerous. However,
it would be nice if "bzr resolve --take-this" would resolve the
conflicts in favour of the on-disk versions.
> Is there some way that bzr can be modified to help a group of bzr
> users (of an unknown size) with the .moved issue?
Yes. You would want to provide an alternative to
bzrlib.transform.resolve_checkout, and then provide an option to use
it in bzrlib.builtins.cmd_checkout.
> Is .moved seen as "a good thing" so often that the default cannot
> be changed?
It is certainly *my* feeling that giving preference to the branch
versions is the correct default. I also think that if we improved our
tools for dealing with conflicts, it would not be a big issue.
> If not, what about prompting the user and telling him what is about
> to happen?
We generally don't prompt the user for anything, because that would
make bzr unsuitable for scripting. Instead, we do what we think the
user asked, and provide means for them to change their mind. There
are a few exceptions where we do prompt, such as "bzr shelve" and "bzr
clean-tree". The first is explicitly interactive. The second does
something dangerous-- it deletes files.
> Or, what about having some kind of configuration (maybe in the
> repository), that suppresses the .moved behavior?
Once there is an option to make bzr behave the way you wish, you can
make it your default using aliases. (For example, I alias "commit" to
"commit --strict") If it was specified in the repository, then it
would vary according to the repository, and that would make bzr's
behaviour inconsistent. Being inconsistent is guaranteed to astonish.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the bazaar