Re: Strange message from "bzr pull"

[Karl Fogel <kfogel@red-bean.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Karl Fogel <kfogel@red-bean.com>
>> Date: Tue, 29 Dec 2009 13:44:21 -0500
>> Cc: lekktu@gmail.com, emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >So does that mean there's a bug in bzr?  If not, then what are
>> >tree-less repositories good for?
>> 
>> The answer to that is "many thing", I think, just not things we happen
>> to be doing here.
>
>OK.  So, since we have this tree in trunk/, what are the reasons to
>keep it pristine, again?  IOW, why not make quick and simple fixes in
>it directly, instead of in another branch?

I *think* that would work fine (though I'm not 100% positive, since I
don't do it myself).

The only reason I didn't document that is that if upstream gets new
changes while the local edits are being made, then one would have to
pull them in before committing -- because, as a bound branch, trunk is
not supposed to diverge from what it's bound to.  But they might
conflict.  Now your local trunk mirror is in a conflicted state.

That's not a disaster -- it's easy enough to resolve things -- but the
point of the trunk mirror is that it's always pristine, so that it can
be used as a merge source for your local feature branches, etc.  That's
why in the other recipes, if you get conflicts, we just say "bzr revert"
and pull, and then re-merge from the local branch to commit upstream.
However, in this scenario, "bzr revert" would lose the *only* copy of
the changes, unlike in all the other scenarios.  So you really have to
resolve the conflict right away, without reverting, and finish the
commit.  Thus trunk spends more time in a non-pristine state than is
ideal, though it's not hard to get out of that if one needs to.

None of this is terribly complicated, and I doubt any developer here
would have a problem handling it, but I wasn't sure it was wise to
introduce that little bit of extra complexity early on, especially as I
didn't have personal experience with it and didn't know if the
likelihood of unexpected gotchas.

So if you test it and it works, and no one thinks of any reason why it
could lead to bad history, then... go for it, I'd say.

-Karl