preparing migration from baz to bzr

[David Allouche]

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.

I pushed after B. I want to push C.

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.

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.
-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051019/9a776334/attachment.pgp