Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 4 and 5
Revision 4 as of 2005-11-08 00:09:38
Size: 2719
Editor: JohnMeinel
Comment:
Revision 5 as of 2005-11-08 00:56:47
Size: 4237
Editor: JohnMeinel
Comment:
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:
There are lots of tools to do some sort of diff, mail it, and then apply it on the other end. A simple `bzr diff -r -10 | gpg --cl | mail mailing@list.com` will be able to do a reasonable job of sending a signed change to a mailing list. It is assumed that people who want a `bzr submit` command would also like to attach some meta-data. It is possible to create a text-based changeset format, which contains all of the meta-information which `bzr` maintains, and apply it on the other end, so that it has all the features of doing a `bzr merge` against the original branch.
Line 48: Line 50:
1. User grabs a public branch, finds a bug, and wants to submit back a small patch back to the mailinglist. The nice use case would be:
{{{
 1. User grabs a public branch, finds a bug, and wants to submit back a small patch back to the mailinglist. The nice use case would be: {{{
Line 57: Line 58:
 People can review the final changes in their mail program, and finally decide to apply this change and commit it: {{{
<save the email to a file>
cat file | bzr apply # or bzr apply file
<double check things are okay>
bzr commit -m "Applied the change from foo"
}}}

 1. As a maintainer, I use `bzr submit` to submit my changes to a pqm. However, since others would not have commit access to the pqm, I want to specify that submissions should go to the mailing list. I publish my branch using `rsync`.

 1. I would like to automatically maintain a branch, such that I can submit to it using email, with a simple procmail filter.
Line 59: Line 71:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: To allow `bzr branch` to know how to set the submit target, there should be a file in the `.bzr/` directory indicating the target. To allow for a different target for people who branch from me, versus my default branch target, there should be 2 files. (`.bzr/submit-to` and `.bzr/children-submit-to`) `bzr branch` should be smart, such that when it creates a branch, it will use `.bzr/children-submit-to` if it is available.

Summary

PQM provides a way to submit merge requests by email and have them automatically applied. It might be nice if this were smoothly integrated with bzr.

Rationale

Erik Bågfors    
<zindar@gmail.com> to mbp, Bazaar-NG

How about adding this kind of functionality into bzr itself?  Look at
how darcs handles it. It's one if the nicest things about darcs.

a darcs "server" can simply be a mail address you mail to, that runs
all mails trough pgp and then applies them if they match (you can add
tests as well by just adding "apply test" to the repo config file).

for example a procmail can look like this

:0:
* ^TOmy darcs repo
|(umask 022; darcs apply --reply user@host.com \
   --repodir /path/to/your/repo --verify /path/to/the/allowed_keys)

That's a dead simple way to set up a "server" for trusted people to submit to.

I don't know how pqm works and it might be lot's better, but having
this functionality built into bzr has lot's of advantages I think.

This has the big advantage that no special kind of server is required. A procmail rule is something almost anyone can set up, including on a desktop/firewalled/not-permanently-connected machine.

Further Details

It would be nice to send the changes as a series of bzr changesets (as mentioned on BzrWishlist).

There should be one command to send the changeset (bzr submit), and one to apply the changeset (bzr apply), to be called manually or from a procmail rule.

Assumptions

There are lots of tools to do some sort of diff, mail it, and then apply it on the other end. A simple bzr diff -r -10 | gpg --cl | mail mailing@list.com will be able to do a reasonable job of sending a signed change to a mailing list. It is assumed that people who want a bzr submit command would also like to attach some meta-data. It is possible to create a text-based changeset format, which contains all of the meta-information which bzr maintains, and apply it on the other end, so that it has all the features of doing a bzr merge against the original branch.

Use Cases

  1. User grabs a public branch, finds a bug, and wants to submit back a small patch back to the mailinglist. The nice use case would be:

    $ bzr branch http://public.com/project
    $ cd project
    <hack hack>
    $ bzr commit -m "Fixed my little bug"
    $ bzr submit

    People can review the final changes in their mail program, and finally decide to apply this change and commit it:

    <save the email to a file>
    cat file | bzr apply # or bzr apply file
    <double check things are okay>
    bzr commit -m "Applied the change from foo"
  2. As a maintainer, I use bzr submit to submit my changes to a pqm. However, since others would not have commit access to the pqm, I want to specify that submissions should go to the mailing list. I publish my branch using rsync.

  3. I would like to automatically maintain a branch, such that I can submit to it using email, with a simple procmail filter.

Implementation

To allow bzr branch to know how to set the submit target, there should be a file in the .bzr/ directory indicating the target. To allow for a different target for people who branch from me, versus my default branch target, there should be 2 files. (.bzr/submit-to and .bzr/children-submit-to) bzr branch should be smart, such that when it creates a branch, it will use .bzr/children-submit-to if it is available.

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Schema Changes

Data Migration

Discussion

This section should house the larger issues that need discussing; you can sprinkle XXXs around the page if you want to keep the smaller open issues in context.

Unresolved Issues

Questions and Answers