preparing migration from baz to bzr

[John A Meinel]

David Allouche wrote:
> On Tue, 2005-10-18 at 08:12 -0500, John Arbash Meinel wrote:
>
>>The two current plugin implementations (bzrtools "bzr push", and my
>>bzr-rsync "bzr rpush") both use rsync to push your changes to the remote
>>branch. Both of them check the remote history, to make sure you aren't
>>overwriting a branch which isn't the same as this one. So when you push,
>>you must have all the local entries. So at present, it really only works
>>for a single developer (if someone pushed and you had committed and
>>wanted to push, your branches have diverged, which push does'nt
>>currently support).
>
>
> I would find it useful to be able to push to a branch whose history
> contains revisions not in the local history.
>
> Here's my scenario: I have bzr branch that contains a few (really a few,
> 2 or 3) patches that I'm trying to get merged upstream. My patches go
> through the mailing list, are reviewed, fixed, then eventually merged.
> Sometimes, I update my branch from upstream and find conflicts. When
> that happens, I fix the conflicting patches and send them again to the
> mailing list. All the merging happens outside of bzr history tracking,
> if only because bzr cannot model cherrypicks (yet?).
>
> The first use case is applying review changes to a patch.
>
> dev  A------.
>       \      \
> ddaa   `-> B  `---> C
>             \    /
>              `--'
>
> After the review fixes, ddaa's history ends in AC.

First off, kudos on your top-notch ASCII art. I will probably adopt it
in the future. Very pretty. :)

Anyway, are you "dev" or "ddaa"? I guess I'm not really clear.

I think you need another branch somewhere. Something like "dev", "ddaa",
"local". Somewhere you are doing the merging (local), and somewhere you
are doing the publishing (push), and somewhere is upstream (dev).
>
> I pushed after B. I want to push C.

Are you saying that you have a published branch. Which you did some
changes to, and now you want to *replace* the branch with the upstream
branch? Because they merged your work, so you want to ignore the fact
that you did it. (You want B to be hidden, not part of revision-history).

>
> The second use case is merging from upstream, while keeping my changes
> on top of the branch and potentially updating them for conflicts.
>
>        (applies C)
> dev   A---> D -> E -> F
>        \               \
> ddaa    `-> B -> C      `-> G -> H
>              \    \      /    /
>               `----\----'    /
>                     \       /
>                      `-----'
>
> After the merging, ddaa's history ends in ADEFGH.
>
> I pushed C, I want to push H.

The way I see what you have written, ddaa's history should be ABCH. I'm
having trouble seeing what merged what, when, because of your (applies
C) comment. Are you saying that the D->E transition contains the same
contents as the B->C transition (cherrypicked patch).

I think maybe with a middle branch inbetween, which shows the work that
you are doing would make things more obvious. Something like the
following. In the following, the arrows indicate merges, regular
commits, pull, while a horizontal line indicates the contents of
.bzr/revision-history

       (applies C)
dev   A---> D -> E -> F
       \               \
ddaa    `-> B -> C      \        G -> H
                  \      \      /
local              `------`-> G -> H

The work flow would be:
bzr branch dev local
cd local
bzr merge ../ddaa
bzr commit -m "G"

At this point, you should be able to "bzr pull" G back into ddaa,
because C is an ancestor of G (this should work right now). My idea is
that "bzr push" should work just like pull, only into from local to
remote. So local G can be pushed onto ddda C, because it is a decendent.

That would leave your ddaa branch as ABCGH.
Is that acceptable? Dev can now just "bzr pull" your ddaa branch,
because G is a decendent of F. Without having to have F as part of your
revision-history (just part of the revision itself).

>
> I could come up with more complex use cases based on these simple cases,
> but I think that is enough to get the idea through. Any resemblance with
> a quilt-like workflow (stgit someone?) is entirely non coincidental.
>
> In both cases, anybody who previously pulled the branch I push to will
> be able to pull again after the second push. Maybe this constraint might
> be undesirable, but let's just tackle one problem at a time.
>
> However, from your description of push (I have no checked the code), I
> would not be allowed to push. I think that's bad.
>
> I think push should be allowed to remove items from the target branch's
> history. At least as long as it does not break pull.

Well, we certainly could support a "--clobber" option. Which would let
you say "I want the published branch to look *exactly* like this one,
don't concern yourself with what it actually looks like now".

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051019/7ff632f8/attachment.pgp