Checkout existing branch to established workspace (.moved)

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-03-23 05:39 PM, Bulgrien, Kevin wrote:
>> -----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?

They don't create checkouts, but they update the contents of checkouts
and rename files to .moved.

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

I'm sorry, but reading the beginning of the e-mail did not make that
clear to me, and I still do not know what you mean.

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

I don't think I said this.

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

I raise the issue of more or less likely, because I think Bazaar's
should behave in ways that are more likely to be useful, and less likely
to be harmful.

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

Unfortunately, we cannot support every workflow equally well by
default, because the needs of some workflows conflict with the needs
of others.  We can only pick the defaults that are most likely to be
helpful or least likely to be harmful.

If you see that as de-valuing minority use cases, I can't really
disagree, but I don't think there's an alternative to having defaults.

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

Right, and there is a conflict between what a user of Bazaar would
expect, based on familiarity with its other commands, and what a user of
another VCS would expect, based on that VCS's checkout command.

>>> 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 suppose the specific issue you're raising with aliases is that they
can only be configured locally, not per-branch or per-location.  When I
implemented aliases, I did that deliberately.  I had previously
implemented and used a VCS interface where the aliases could vary
per-branch, and decided that it was too confusing.

> I can see what you are saying about repository specific
> configuration.

Indeed, it's basically the same issue that you describe about aliases--
that it leads to inconsistent behaviour.

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

But you wouldn't want the behaviour to vary among your personal
repositories, right?  The virtue you see in per-repository configuration
is that it would be non-local.

It sounds like your ideal would be a configuration mechanism that
ensured all your work spaces behaved the same way.  And you might want a
way to provide an initial configuration for your colleagues.  Is that
right?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9x5TQACgkQ0F+nu1YWqI19SgCdEHSJbSo4LWGb9pHBSiTF0Q9a
0aUAn3RNldLJUewl6d0sdjGH7HPRQQE3
=pmfv
-----END PGP SIGNATURE-----