<br><br><div class="gmail_quote">uhhh yeah, i was recovering from a mac windowserver crash and i forgot who the conversation was with, since its obviously vila when you look at it.</div><div class="gmail_quote"><br></div><div class="gmail_quote">
On Fri, Mar 23, 2012 at 2:41 PM, Jelmer Vernooij <span dir="ltr"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Mark,<br>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Jelmer<br>
<br>
Am 23/03/12 21:13, schrieb Mark Grandi:
<div><div class="h5"><blockquote type="cite">
<div>(sorry, resent. I suck at mailing lists)</div>
<div><br>
</div>
<div>Me and Jelmer had a conversation about this on IRC (<a href="http://bpaste.net/show/25779/" target="_blank">http://bpaste.net/show/25779/</a>)
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. </div>
<div><br>
</div>
<div>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<br>
</div>
<br>
<div class="gmail_quote">On Fri, Mar 23, 2012 at 7:06 AM,
Bulgrien, Kevin <span dir="ltr"><<a href="mailto:Kevin.Bulgrien@gdsatcom.com" target="_blank">Kevin.Bulgrien@gdsatcom.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a few cases where I have a reference shared
repository/branch stored<br>
somewhere. There are other locations that I want to compare
to that reference<br>
branch that should have the capability of being used to update
the branch as<br>
needed.<br>
<br>
Scenarios might be along the lines of using bzr to help a user
standardize a<br>
home directory across multiple systems - including when
bringing new systems<br>
up, controlling system configuration (along the lines of
etckeeper), or<br>
converting sandboxes of other VCS over to bzr after converting
the other VCS<br>
repository to a bzr repository/branch. One might also think
of having a<br>
workspace based on a tarball, and subsequently deciding that
the workspace<br>
should be made a checkout of a project branch.<br>
<br>
The idea is that some shared repository/branch is checked out
into an existing<br>
workspace that is well established and working per the owner's
wishes, and,<br>
to make a point, has over a hundred files that have minor
variations to the<br>
branch.<br>
<br>
Now a the point the owner decided to checkout a project branch
so that the<br>
branch is useful for merging stuff from the branch or
committing to it, the<br>
owner does `bzr co someplace .`. All of a sudden over a
hundred of these<br>
occur:<br>
<br>
Conflict adding file blah. Moved existing file to blah.moved.<br>
<br>
Owner screams in anguish. The workspace is now broken. He
thinks software<br>
should operate by the principle of least astonishment:<br>
<br>
<a href="http://en.wikipedia.org/wiki/Principle_of_least_astonishment" target="_blank">http://en.wikipedia.org/wiki/Principle_of_least_astonishment</a><br>
<br>
In the owner's experience, another VCS doesn't choose to do
things for him<br>
unless he asks it to. He realizes that by doing `bzr co` the
way he did, that<br>
in a sense he asked it to to all that moving (without
realizing it) BUT what<br>
he didn't ask it to do was BREAK his workspace. That other
VCS would have<br>
complained about conflicts and needing to move the existing
stuff out of the<br>
way (or something) every time he asked for status, tried to
update, etc, but,<br>
it would NOT have decided it needed to automatically move
conflicts. On the<br>
otherhand, this other VCS would have moved and renamed old
files if the owner<br>
had specifically included a command-line option that
explicitly requested<br>
something that might be dangerous.<br>
<br>
In short, the assumption of `bzr co` that it should rename
files by default is<br>
not friendly.<br>
<br>
Realizing that this owner is coming to bzr late in the game,
perhaps the<br>
community does not agree, however, there is no option even to
disable this, in<br>
some scenarios, behavior. I have searched around and found a
number of other<br>
bzr users who felt the same way I do, and some on #bzr also
agreed that my<br>
view was not altogether unreasonable.<br>
<br>
Is there some way that bzr can be modified to help a group of
bzr users (of<br>
an unknown size) with the .moved issue? Is .moved seen as "a
good thing" so<br>
often that the default cannot be changed? If not, what about
prompting the<br>
user and telling him what is about to happen? Or, what about
having some<br>
kind of configuration (maybe in the repository), that
suppresses the .moved<br>
behavior?<br>
<br>
Perhaps new adopters of bzr are most impacted, but, even
knowing about .moved,<br>
I am not sure how to checkout a branch into a pre-existing
workspace without<br>
the checkout breaking it by renaming lots of files. I am also
in the position<br>
of considering transitioning my workplace over from another
VCS to bzr, and<br>
see this as one of the pain factors associated with advocating
that change.<br>
<br>
Respectfully,<br>
<br>
Kevin Bulgrien<br>
<br>
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.<br>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br>