Checkout existing branch to established workspace (.moved)

[Bulgrien, Kevin]

> -----Original Message-----
> [mailto:bazaar-bounces at lists.canonical.com] On Behalf Of Aaron Bentley

> 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.

Do merge, pull, and other commands create checkouts and .moved files?

If not, then I do not follow how this is relevant to the .moved issue.

Perhaps merge, pull, and other commands create .moved files, but there
seems to be a very special case with checkout that significantly changes
the situation to warrant a difference of behavior that correlates with
the difference in environment.

> 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
> alternative.

Of relevance to this is illustrated by referring to part of the premise
established at the beginning of the e-mail.

| 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.

In this case the branch is not the owner's version of the software.
Broken is when the owner can no longer build this software the way
he did before `bzr co`.

I'm not sure how to answer more or less likely.  That's not really the
point being made.  Of course that depends on the use case and whether
or not more people use that use case or not.

> 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
> versions' expectations.

Use of "most" above is dependent on assumptions that seem to de-value
certain workflows.

Part of the reason bzr is being discussed by this poster is because
the implementation largely is done in a way that allows users of other
VCS to choose workflows they are familiar with and choose to keep.

I can agree that in many cases using a mixed set of files is problematic
for most software development.  Since bzr is probably mostly used for
controlling software sources other than heavily modified tar drops, I
can't particularly argue vehemently that use of "most" is probably
true in a universal sense.

> > 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.

It probably is not dangerous.  It is inconvenient for certain workflows.

Unfortunately I am having a hard time re-producing the situation I was
in a few nights ago.  I feel certain that the first time I encountered
this, I got so balled up in trying to figure out how to fix the
situation that I ended up losing files.  I will not state that this was
bzr's fault, but I had difficulty because of the behavior.  Maybe this
was because I was so new to bzr?  It made an impression that was not
good.

> > 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.

bzr should be suitable for scripting - I agree.  I heavily script
with my other VCS.  I script checkout quite a bit too.

> > 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.

My personal feeling is that aliases are bad.  They stick to the workspace
and are lost when I move from place to place.  They make me think that a
certain behavior is the way it happens everywhere, so I am astonished
when I do not have my workspace with me and things behave differently
I am used to.

I can see what you are saying about repository specific configuration.
Personal aliases impact only me.  Repositories defaults affect other
people too.  On the other hand, when I work primarily with my own
repositories, I can make sure they are all set up the same way.  That
might or might not astonish my colleagues depending on whether they do
or do not work with bzr in any other environment.  In my case, they do
not, but that is probably an outside case.  They only use a VCS at work
with private repositories.

I will reiterate what I said on IRC.  I am not interested in coming on
board and saying bzr is broken without entertaining an opportunity to
learn what is better about it than where I came from.  I have, however,
already been involved in triggering a change that is due out in 2.6...
so I know that I have the ability to provide an opportunity to nudge
bzr more into the mode of being friendly to many differing workflows.

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.