[RFC] Push via e-mail?

[John A Meinel]

Jan Hudec wrote:
> On Sun, Feb 19, 2006 at 09:21:37 +0100, Erik Bågfors wrote:
>> 2006/2/19, Alexander Belchenko <bialix at ukr.net>:
>>> I need to organize cooperative work with my co-worker. Unfortunately he
>>>   cannot use bzr itself for push and pull changes. We may use only e-mail.
>>> I'd like to know is there possible to create plugin for pushing changes
>>> from one to other (assume that branches not diverged) via e-mail?
>>>
>>> I suppose this plugin should prepare archive (zip or tar.gz) with all
>>> needed info for pushing: new items from revision-store, new and updates
>>> items from weave-store and probably new inventory.weave? And when such
>>> archive will be received via e-mail on another end plugin should
>>> implement pull operation based on this data.
>>>
>>> Any hints how to implement this behaviour?
>> This is planed. See http://bazaar.canonical.com/SubmitByMail
>>
>> (and of course, Johns answer)
>>
>> I think something like this should be built into bzr sooner or later. 
>> I my mind, The following commands
>> cd branch1
>> bzr submit /tmp/foo
>> cd ../branch2
>> bzr apply /tmp/foo
>>
>> Should produce the exact same thing as
>> cd branch2
>> bzr merge ../branch1
>>
>> But the first case is easier to mail or course :)
>> This makes people that can't put up a branch somewhere, still be first
>> class bzr citizens.
> 
> There is a small problem though (see Darcs, which does this). You need to
> know /what/ to submit.
> 
> Darcs does it by refering to target repository -- which has the disadvantage,
> that one of the repositories must be accessible to the other via network.
> 
> I am inclined to think, that in bzr submit should take a revision argument
> instead. So you would say:
> 
>     bzr submit -r ancestor:../branch2.. /tmp/foo
>                          ^^ Um, how does ancestor: specification work with
> 			 relative paths? If .. is a separator...
> 
> perhaps with a shorthand
> 
>     bzr submit --target ../branch2
> 
> equivalent to the above (and as side-efect memoizing the target).
> 
> This would have the advantage, that you could say:
> 
>     bzr submit -r 1526.. /tmp/foo
> 
> if you can't access the target, but know what you need to send by other
> means.
> 
> It should also allow for something like:
> 
>     bzr submit --target http://bazaar-ng.org/bzr/bzr.dev \
> 	--mail bazaar-ng at lists.canonical.com
> 
> which would invoke a mail client to actually send the submission.
> And with a bit of magic
> 
>     bzr submit --mail
> 
>     (which would use recorded target and read mail from that target's
>     config)
> 
> Perhaps even most dwimmy
> 
>     bzr submit --target http://bazaar-ng.org/bzr/bzr.dev \
> 	bazaar-ng at lists.canonical.com
> 
> with remembering reducing to
> 
>     bzr submit
> 

I definitely think it is important to figure out how the UI should
evolve. You probably want to put your thoughts into SubmitByMail on the
Wiki.

My changeset plugin had 2 modes of operation. You could do:

bzr cset ../other/branch [local/branch]

Or you could do

bzr cset -r 1000

The first would give you the changeset that would apply against
'../other/branch' to yield the local revision, including all of the
ancestry that '../other/branch' was missing. While 'bzr cset -r 1000'
would just give you the changeset for revision 1000 against its first
parent.

Remember, though. You don't need to actually access the other person's
branch. You just need a local copy of their branch. (Which is as
up-to-date as you know about it).

For the 'apply' operation, we can do both a 'merge' type of application,
or we can 'pull' type operation. So you could keep a local mirror of the
remote tree, with just submit and apply. Then you have an obvious way of
supplying a 'target' branch.

I never worked out exactly how 'submit' should work. I focused more on
'bzr cset'. Which I think is the underlying interface, and submit is
layered on top of that.

One thing that we discussed, is that branches can have a default 'submit
to here' in their metadata. And if you 'bzr get' that branch, it sets
the initial submit target.

That way, when you have a public branch, like bzr, you can have people
do 'bzr get http://bazaar; hack hack; bzr commit; bzr submit' (the
commit may be optional). And it would send an email to the mailing list
for people to review.

That would mean the default target branch is 'parent' and a default
submit-to location is set. We also wanted the 'get' submit target, to be
different from the specific branches submit target. So that I can have
my submit target be a PQM, but people who get my branch would default to
emailing me for review.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060219/175c3126/attachment.pgp