Cannot merge bundles created without referencing another branch.

[John Arbash Meinel]

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

Paul Moore wrote:
> On 09/10/2007, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> Specifically, I have 1 branch of my homework assignment. I submit it at
>> revision 8. And then they ask for changes. So I want to send the changes
>> from revision 8 to the new tip.
>>
>> bzr send -r 8..-1
>>
>> Seems like a really nice, simple, and straightforward way to do that.
> 
> As a complete novice, I have to say that my immediate reaction was
> surprise, if you're saying that you can't do that.
> 
> I tried to understand *why* you couldn't and rapidly got confused. My
> mental model says that this is a more robust and automated way of
> doing the equivalent of bzr diff -r 8..-1, save it as a patch, send it
> off. Clearly, it isn't, when I start looking at the documentation, but
> I've no idea what to make of the concept of a "submit branch" or a
> "public branch".
> 
> The questions I immediately came up with when I started thinking about
> this were:
> 
> 1. How *do* I do something like bzr diff -r 8..-1, but rather than
> producing a patch file, produce a binary-safe,
> copy/move/delete-preserving "thing" (I want to say "bundle", but I
> don't know for sure how the technical meaning of the word "bundle"
> might differ from what I'm describing).
> 
> 2. What precisely is bzr send intended *for*, if not the above use case?
> 
> Please understand, that for (1), an answer of "you shouldn't be doing
> that" isn't really enough. Why on earth not? I'd be quite happy using
> bzr diff to send a patch if upstream didn't use bzr - why should it be
> any harder if upstream does use bzr?
> 
> For (2), I'm not trying to argue that bzr send isn't useful, it's just
> that as a newcomer, I clearly seem to be expecting something different
> from it - and so when I find out I'm wrong, I'd like to understand
> what concepts or workflow I'm missing.
> 
> Paul.
> 


Well, technically 'bzr send' is supposed to be more clever than "bzr
diff -r 8..-1". Specifically, if you have done changes, you can just do:

bzr send http://project/trunk

And if they have a 'submit_to' address set up, it will just spawn your
mail program and send all of the necessary changes as an attachment.
(You can also use --output to direct it to a file, or --mail-to to send
it to your preferred address)

"bzr send -r 8..-1 http://project/trunk"

Will send a cherrypick request to upstream. Such that you are
specifically asking them not to merge any changes prior to 8. (So don't
merge the changes for 6, 7 or 8, only the changes *after* 8).

The reason it still requires the URL, is because it is doing the hard
work of figuring out what upstream (submit location) really needs to be
able to cleanly merge your changes.

"public location" is a bit of noise that doesn't need to be worried
about just yet, it has to do with how Merge Directives can ask you to
merge a branch from a URL, rather than sending the patch information
directly. (Since your local filesystem is not likely to be accessible to
upstream, you have to tell them what URL they can get it from. ie the
"public location").


In its current form, it is a lot harder to generate a "broken" request.
By "broken" I mean that when you send it, the recipient cannot merge it
(because you didn't include enough context). The downside is that it
doesn't work unless you have access to a target (submit/upstream/source)
branch.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHC+sDJdeBCYSNAAMRAmdzAKCRCTsXX+FegrQPSh0EP0YbSrv6DACeOGks
kbe+N1HCg3FL2SOb4hyKRpM=
=AtaX
-----END PGP SIGNATURE-----